En els dos primers articles, vaig plantejar el tema de l'automatització i n'he descrit el marc, en el segon vaig fer una digressió cap a la virtualització de xarxes, com a primer enfocament per automatitzar la configuració del servei.
I ara és el moment de dibuixar un diagrama de la xarxa física.

Si no us trobeu a poca distància amb l'organització de xarxes de centres de dades, us recomano molt començar per articles sobre ells.

Tots els llançaments:

• 0. ADSM. Part Zero. Planificació
• 1. ADSM. Primera part (que és després de zero). Virtualització de la xarxa
• 2. ADSM. Segona part. Disseny de xarxa

Les pràctiques descrites en aquesta sèrie haurien de ser aplicables a qualsevol tipus de xarxa, qualsevol escala i qualsevol varietat de proveïdors (no). Tanmateix, és impossible descriure un exemple universal de l'aplicació d'aquests enfocaments. Per tant, em centraré en l'arquitectura moderna de la xarxa DC: Fàbrica de Kloz.
Farem DCI a MPLS L3VPN.

A la part superior de la xarxa física, hi ha una xarxa de superposició des de l'amfitrió (pot ser VXLAN d'OpenStack o Tungsten Fabric, o qualsevol altra cosa que només requereixi connectivitat IP bàsica de la xarxa).

En aquest cas, obtenim un escenari relativament senzill per a l'automatització, perquè tenim molts equips configurats de la mateixa manera.

Escollirem un DC esfèric al buit:

• Una versió de disseny a tot arreu.
• Dos venedors que formen dos plans de xarxa.
• Un DC és com un altre com dues gotes d'aigua.

Contingut

• Topologia física
• Encaminament
• Pla IP
• Laba
• Conclusió
• links útils

Per exemple, el nostre proveïdor de serveis LAN_DC allotja vídeos de formació sobre la supervivència d'ascensors bloquejats.

A les megaciutats, això és molt popular, de manera que necessiteu moltes màquines físiques.

En primer lloc, descriuré la xarxa aproximadament tal com m'agradaria veure-la. I després simplificaré per al laboratori.

Topologia física

Ubicacions

LAN_DC tindrà 6 DC:

• Rússia (RU):
  • Moscou (msk)
  • Kazan (kzn)

• Espanya (SP):
  • Barcelona (bcn)
  • Màlaga (mlg)

• Xina (CN):
  • Xangai (xa)
  • Xi'an (sia)

Dins del DC (Intra-DC)

Tots els DC tenen xarxes de connectivitat interna idèntiques basades en la topologia Klose.
Què són les xarxes Kloz i per què ho són exactament? article.

Cada DC té 10 bastidors amb cotxes, es numeraran com A, B, C I així successivament.

Hi ha 30 màquines a cada bastidor. No ens interessaran.

A més, a cada bastidor hi ha un interruptor al qual estan connectades totes les màquines, això és Interruptor superior del bastidor - ToR o en cas contrari, pel que fa a la fàbrica Klose, l'anomenarem Full.

Esquema general de la fàbrica.

Els posarem nom XXX-fullYOn XXX - abreviatura de tres lletres DC, i Y - número de sèrie. Per exemple, kzn-fulla11.

En els meus articles, em permetré utilitzar els termes Leaf i ToR de manera bastant frívola com a sinònims. Tanmateix, cal recordar que no és així.
ToR és un interruptor muntat en bastidor al qual es connecten les màquines.
Leaf és el paper d'un dispositiu en una xarxa física o un commutador de primer nivell en termes de la topologia Klose.
És a dir, Fulla != ToR.
Així, un Leaf pot ser un interruptor EndofRaw, per exemple.
Tanmateix, en el marc d'aquest article, encara els tractarem com a sinònims.

Cada interruptor ToR està connectat al seu torn a quatre interruptors d'agregació superiors: Espina. Sota el de Spine, s'assigna un bastidor al DC. L'anomenarem així: XXX-columna vertebralY.

En el mateix bastidor hi haurà equips de xarxa per a la connectivitat entre DC - 2 encaminadors amb MPLS a bord. Però en general, aquests són els mateixos Tors. És a dir, des del punt de vista dels interruptors Spine, no importa el ToR habitual amb màquines connectades o un encaminador per a DCI, una maleïda cosa.

Aquests TdR especials s'anomenen Fulla de vora. Els posarem nom XXX-bordY.

Es veurà així.

Al diagrama de dalt, realment vaig col·locar la vora i la fulla al mateix nivell. Xarxes clàssiques de tres capes ens va ensenyar a considerar l'enllaç ascendent (de fet, d'aquí el terme) com a enllaços. I aquí resulta que l'"enllaç ascendent" DCI torna a baixar, cosa que trenca una mica la lògica habitual per a alguns. En el cas de les xarxes grans, quan els centres de dades es divideixen en unitats encara més petites - POD's (Punt de lliurament), assignar individual Edge-POD's per a DCI i accés a xarxes externes.

Per facilitar la percepció en el futur, encara dibuixaré Edge sobre Spine, tot i que tindrem en compte que no hi ha intel·ligència a Spine i no hi ha diferències quan es treballa amb Full normal i amb Edge-leaf (encara que hi pot haver matisos). , però en general Això és cert).

Diagrama de fàbrica amb fulles de vora.

La fulla, la columna vertebral i la vora de la trinitat formen una xarxa o fàbrica de subjecció.

La tasca de la fàbrica de xarxa (llegiu Underlay), com ja hem definit a darrer número, molt, molt senzill: proporcionar connectivitat IP entre màquines tant dins del mateix DC com entre elles.
És per això que la xarxa s'anomena fàbrica, igual que, per exemple, una fàbrica de commutació dins de caixes de xarxa modulars, sobre les quals podeu llegir més informació a SDSM14.

En general, aquesta topologia s'anomena fàbrica, perquè el teixit en traducció és un teixit. I és difícil estar en desacord:

La fàbrica és completament L3. Sense VLAN, sense difusió: aquests són els meravellosos programadors que tenim a LAN_DC, poden escriure aplicacions que viuen en el paradigma L3 i les màquines virtuals no requereixen la migració en directe amb desar l'adreça IP.

I una vegada més: la resposta a la pregunta per què la fàbrica i per què L3 està en un separat article.

DCI - Interconnexió del centre de dades (Inter-DC)

El DCI s'organitzarà amb l'ajuda d'Edge-Leaf, és a dir, són el nostre punt de sortida a l'autopista.
Per simplificar, suposem que els DC estan interconnectats per enllaços directes.
Excloem de la consideració la connexió externa.

Sóc conscient que cada vegada que elimino un component, simplifico molt la xarxa. I quan automatitzem la nostra xarxa abstracta, tot anirà bé, però apareixeran crosses a la real.
Això és cert. I, tanmateix, l'objectiu d'aquesta sèrie és pensar i treballar enfocaments, i no resoldre heroicament problemes ficticis.

A Edge-Leafs, la capa inferior es col·loca a la VPN i es transmet a través de la columna vertebral MPLS (el mateix enllaç directe).

Aquí teniu un esquema de primer nivell obtingut.

Encaminament

Per a l'encaminament dins del DC, utilitzarem BGP.
A la columna vertebral OSPF+LDP MPLS.
Per a DCI, és a dir, l'organització de la connectivitat a la base: BGP L3VPN sobre MPLS.

Esquema general d'encaminament

No hi ha OSPF ni ISIS a la fàbrica (protocol d'encaminament prohibit a la Federació Russa).

I això vol dir que no hi haurà descobriment automàtic ni càlcul dels camins més curts, només configuracions de protocol, barri i polítiques manuals (en realitat automàtica, aquí parlem d'automatització).

Esquema d'encaminament BGP dins de DC

Per què BGP?

N'hi ha RFC sencer anomenat Facebook i Arista, que explica com construir molt gran xarxes de centres de dades amb BGP. Es llegeix gairebé com una ficció, el recomano molt per a una tarda lànguida.

També hi ha una secció sencera al meu article dedicada a això. On et puc portar i enviar.

Però tot i així, en resum, cap IGP és adequat per a xarxes de grans centres de dades, on el nombre de dispositius de xarxa arriba a milers.

A més, l'ús de BGP a tot arreu us permetrà no utilitzar el suport per a diversos protocols diferents i la sincronització entre ells.

Amb el cor, a la nostra fàbrica, que molt probablement no creixerà ràpidament, OSPF seria suficient per als nostres ulls. Aquest és en realitat el problema dels mega escaladors i dels titans del núvol. Però fantasiegem amb només uns quants problemes que ho necessitem i utilitzarem BGP, tal com va arribar Peter Lapukhov.

Polítiques d'encaminament

Als interruptors Leaf, importem prefixos de les interfícies de xarxa Underlay a BGP.
Tindrem una sessió de BGP entre cadascun un parell de Leaf-Spine, en què aquests prefixos Underlay s'anunciaran a través de la xarxa aquí i allà.

Dins d'un centre de dades, distribuirem les dades específiques que hem importat a Tor. A Edge-Leafs, els agregarem i els anunciarem als DC remots i els enviarem a Tors. És a dir, cada Tor sabrà exactament com arribar a un altre Tor en el mateix DC i on és el punt d'entrada per arribar al Tor en un altre DC.

A DCI, les rutes es transmetran com a VPNv4. Per fer-ho, a l'Edge-Leaf, la interfície cap a la fàbrica es col·locarà al VRF, anomenem-lo UNDERLAY, i el barri amb la columna vertebral a la Edge-Leaf s'elevarà dins del VRF, i entre les Edge-Leafs. a la família VPNv4.

També prohibirem tornar a anunciar les rutes rebudes d'espines de tornada a ells.

A Leaf and Spine no importarem Loopbacks. Només els necessitarem per determinar l'identificador del router.

Però a Edge-Leafs l'importem a Global BGP. Entre les adreces de Loopback, Edge-Leafs establirà una sessió BGP en una família VPN IPv4 entre si.

Entre dispositius EDGE, tindrem un tronc estirat a OSPF + LDP. Tot en una zona. Configuració extremadament senzilla.

Aquí teniu una imatge amb el recorregut.

BGP ASN

Edge Leaf ASN

A Edge-Leafs hi haurà un ASN a tots els DC. És important que hi hagi iBGP entre els Edge-Leafs, i no ens trobem amb els matisos d'eBGP. Sigui 65535. En realitat, podria ser un número AS públic.

Columna vertebral ASN

A Spine, tindrem un ASN per DC. Comencem aquí des del primer número de la gamma d'AS privats: 64512, 64513, etc.

Per què ASN a DC?

Descompondrem aquesta pregunta en dues:

• Per què el mateix ASN a totes les espines d'un DC?
• Per què són diferents en diferents DC?

Per què el mateix ASN a totes les espines d'un DC?

Així serà l'AS-Path de la ruta de subjecció a la Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Quan intenteu anunciar-lo de nou a Spine, s'eliminarà perquè el seu AS (Spine_AS) ja és a la llista.

Tanmateix, dins del DC, estem perfectament satisfets que les vies Underlay que han pujat a l'Edge no podran baixar. Tota la comunicació entre hosts dins del DC s'ha de produir dins del nivell de les espines.

Al mateix temps, les rutes agregades d'altres DC arribaran lliurement als Tors -el seu AS-Path només contindrà ASN 65535 - el nombre d'AS Edge-Leafs, perquè va ser en ells on es van crear.

Per què són diferents en diferents DC?

Teòricament, és possible que hàgim d'arrossegar Loopback i algunes màquines virtuals de servei entre DC.

Per exemple, a l'amfitrió executarem Route Reflector o el mateix VNGW (Virtual Network Gateway), que es bloquejarà amb Tor mitjançant BGP i anunciarà el seu loopback, que hauria d'estar disponible a tots els DC.

Així doncs, així serà el seu AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

I no hi hauria d'haver repetits ASN enlloc.

És a dir, Spine_DC1 i Spine_DC2 han de ser diferents, igual que leafX_DC1 i leafY_DC2, que és exactament al que ens estem apropant.

Com probablement ja sabeu, hi ha hacks que us permeten acceptar rutes amb ASN duplicats malgrat el mecanisme de prevenció de bucles (permet entrar a Cisco). I fins i tot té usos legítims. Però aquest és un forat potencial en l'estabilitat de la xarxa. I personalment hi vaig caure un parell de vegades.

I si tenim l'oportunitat de no utilitzar coses perilloses, la farem servir.

Full ASN

Tindrem un ASN individual a cada commutador Leaf de tota la xarxa.
Ho fem pels motius indicats anteriorment: AS-Path sense bucles, configuració BGP sense marcadors.

Perquè les rutes entre Leafs passin sense problemes, AS-Path hauria de tenir aquest aspecte:
[leafX_ASN, spine_ASN, leafY_ASN]
on leafX_ASN i leafY_ASN estaria bé que fossin diferents.

Això també és necessari per a la situació amb l'anunci del loopback VNF entre DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Utilitzarem un ASN de 4 bytes i el generarem en funció de l'ASN de la columna vertebral i el número de l'interruptor Leaf, és a dir, així: Spine_ASN.0000X.

Aquí teniu una imatge així amb ASN.

Pla IP

Bàsicament, hem d'assignar adreces per a les connexions següents:

1. Subposar adreces de xarxa entre el ToR i la màquina. Han de ser únics dins de tota la xarxa perquè qualsevol màquina es pugui comunicar amb qualsevol altra. Gran ajust 10/8. Per cada bastidor / 26 amb un marge. Assignarem /19 per DC i /17 per regió.
2. Adreces d'enllaç entre Full/Tor i Spine.

   M'agradaria assignar-los algorítmicament, és a dir, calcular a partir dels noms dels dispositius que s'han de connectar.

   Que sigui... 169.254.0.0/16.
   És a dir, 169.254.00X.Y/31On X - Número de columna, Y — Xarxa P2P /31.
   Això us permetrà executar fins a 128 bastidors i fins a 10 Spine al DC. Les adreces d'enllaç es poden (i es repetiran) de DC a DC.

3. Joint Spine - Edge-Leaf s'organitza en subxarxes 169.254.10X.Y/31, on exactament el mateix X - Número de columna, Y — Xarxa P2P /31.
4. Enllaça adreces des d'Edge-Leaf a la columna vertebral MPLS. Aquí la situació és una mica diferent: la unió de totes les peces en un sol pastís, de manera que no podreu reutilitzar les mateixes adreces, heu de triar la següent subxarxa gratuïta. Per tant, prenem com a base 192.168.0.0/16 i ens en sortirem lliures.
5. Adreces de loopback. Donem-los tota la gamma 172.16.0.0/12.
   • Full - /25 cadascun al DC - els mateixos 128 bastidors. Assigna /23 per regió.
   • Spine - per /28 al DC - fins a 16 Spine. Assigna /26 per regió.
   • Edge-Leaf - /29 a DC - fins a 8 caixes. Assigna /27 per regió.

Si no tenim prou rangs assignats a la DC (i no els tindrem - pretenem ser hiperescaladors), simplement seleccionem el següent bloc.

Aquí teniu una imatge amb l'adreça IP.

Loopbacks:

Prefix
Paper del dispositiu
Regió
ДЦ

172.16.0.0/23
vora
 
 

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
xa

172.16.0.72/29
sia

172.16.2.0/23
espina
 
 

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
xa

172.16.2.144/28
sia

172.16.8.0/21
full
 
 

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
xa

172.16.12.128/25
sia

Sota:

Prefix
Regió
ДЦ

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
xa

10.1.32.0/19
sia

Laba

Dos venedors. Una xarxa. ADSM.

Juniper + Arista. Ubuntu. Bona vella Eva.

La quantitat de recursos a la nostra màquina virtual a Miran encara és limitada, de manera que per a la pràctica utilitzarem una xarxa tan simplificada fins al límit.

Dos centres de dades: Kazan i Barcelona.

• Dos girs cadascun: Juniper i Arista.
• Un torus (Fulla) a cadascun: Juniper i Arista, amb un amfitrió connectat (per a això prenem una IOL Cisco lleugera).
• Un node Edge-Leaf cadascun (només Juniper fins ara).
• Un commutador de Cisco per governar-los tots.
• A més de les caixes de xarxa, s'ha llançat un gestor de màquines virtuals. Sota Ubuntu.
  Té accés a tots els dispositius, executarà sistemes IPAM / DCIM, un munt d'scripts Python, ansible i qualsevol altra cosa que puguem necessitar.

Configuració completa tots els dispositius de xarxa, que intentarem reproduir mitjançant l'automatització.

Conclusió

També s'accepta? Sota cada article per fer una breu conclusió?

Així que hem escollit de tres nivells Xarxa Kloz dins del DC, perquè esperem molt trànsit Est-Oest i volem ECMP.

Vam dividir la xarxa en física (subposició) i virtual (superposició). Al mateix temps, la superposició comença des de l'amfitrió, simplificant així els requisits de la capa de fons.

Escolliu BGP com a protocol d'encaminament de l'encaminador per la seva escalabilitat i flexibilitat de polítiques.

Tindrem nodes separats per organitzar DCI - Edge-leaf.
Hi haurà OSPF+LDP a la columna vertebral.
DCI s'implementarà basant-se en MPLS L3VPN.
Per als enllaços P2P, calcularem les adreces IP de manera algorítmica en funció dels noms dels dispositius.
Els loopbacks s'assignaran segons el paper dels dispositius i la seva ubicació seqüencialment.
Prefixos de subjecció: només als interruptors de fulla en sèrie en funció de la seva ubicació.

Suposem que ara mateix no tenim cap equip instal·lat.
Per tant, els nostres propers passos seran introduir-los en sistemes (IPAM, inventari), organitzar l'accés, generar una configuració i desplegar-la.

En el següent article, tractarem Netbox, un sistema d'inventari i gestió de l'espai IP en un DC.

Gràcies

• Andrey Glazkov també conegut com a @glazgoo per a la correcció i edició
• Alexandru Klimenko també conegut com @v00lk per a la correcció i edició
• Artyom Chernobay per a KDPV

Font: www.habr.com