In i primi dui articuli, aghju suscitatu u prublema di l'automatizazione è hà abbozzatu u so quadru, in u sicondu aghju fattu un ritiru in a virtualizazione di a rete, cum'è u primu avvicinamentu per automatizà a cunfigurazione di servizii.
Avà hè u tempu di disegnà un diagramma di a reta fisica.

Se ùn site micca familiarizatu cù a creazione di rete di centri di dati, vi cunsigliu assai di principià articuli nantu à elli.

Tutti i prublemi:

• 0. ADSM. Parte Zero. Pianificazione
• 1. ADSM. A prima parte (chì hè dopu à zero). Virtualizazione di a rete
• 2. ADSM. A seconda parte. Disegnu di a rete

I pratichi descritti in questa serie deve esse applicabile à ogni tipu di rete, ogni dimensione, cù qualsiasi varietà di venditori (micca). Tuttavia, hè impussibile di discrivà un esempiu universale di l'applicazione di sti approcci. Dunque, mi focalizeraghju nantu à l'architettura muderna di a rete DC: Fabbrica di Kloz.
Faremu DCI nantu à MPLS L3VPN.

Una reta Overlay corre nantu à a reta fisica da l'ospitu (questu puderia esse VXLAN d'OpenStack o Tungsten Fabric o qualsiasi altra cosa chì richiede solu una cunnessione IP basica da a reta).

In questu casu, avemu un scenariu relativamente simplice per l'automatizazione, perchè avemu assai equipamentu chì hè cunfiguratu in u listessu modu.

Sceglieremu un DC sfericu in u vacuum:

• Una versione di disignu in ogni locu.
• Dui venditori chì formanu dui piani di rete.
• Un DC hè cum'è un altru cum'è dui piselli in un pod.

Cuntenuti

• Topulugia fisica
• Routing
• pianu IP
• Laba
• cunchiusioni
• E ligami utili

Lasciate chì u nostru Fornitore di serviziu LAN_DC, per esempiu, ospita video di furmazione nantu à a sopravvivenza in ascensori bloccati.

In megacities questu hè assai populari, cusì avete bisognu di assai macchine fisiche.

Prima, descriveraghju a reta cum'è mi piacerebbe esse. È dopu simplificà per u labburatoriu.

Topulugia fisica

Locazioni

LAN_DC averà 6 DC:

• Russia (RU):
  • Mosca (msk)
  • Kazan (kzn)

• Spagna (SP):
  • Barcelona (bcn)
  • Malaga (MLG)

• Cina (CN):
  • Shanghai (sha)
  • Xi'an (sia)

Dentru DC (Intra-DC)

Tutti i DC anu una rete di cunnessione interna identica basata nantu à a topologia Clos.
Chì tippu di rete Clos sò è perchè sò in un separatu articulu.

Ogni DC hà 10 racks cù machini, seranu numerati cum'è A, B, C E accussì.

Ogni rack hà 30 machini. Ùn ci interessanu micca.

Ancu in ogni rack ci hè un switch à quale tutte e macchine sò cunnessi - questu hè Top of the Rack switch - ToR o altrimenti, in quantu à a fabbrica di Clos, a chjameremu Leaf.

Schema generale di a fabbrica.

Li chjameremu XXX- fogliaYinduve XXX - abbreviazione di trè lettere DC, è Y - numeru d'ordine. Per esempiu, kzn-foglia11.

In i mo articuli mi permetteraghju di utilizà i termini Leaf è ToR piuttostu frivolmente cum'è sinonimi. Tuttavia, ci vole à ricurdà chì questu ùn hè micca u casu.
ToR hè un switch installatu in un rack à quale e macchine sò cunnessi.
Leaf hè u rolu di un dispositivu in una reta fisica o un cambiamentu di primu livellu in quantu à a topologia di Cloes.
Hè, Foglia != ToR.
Allora Leaf pò esse un switch EndofRaw, per esempiu.
Tuttavia, in u quadru di stu articulu, li tratteremu sempre cum'è sinonimi.

Ogni interruttore ToR hè a so volta cunnessu à quattru interruttori di aggregazione di livellu più altu - Spine. Un rack in u DC hè attribuitu per Spines. L'avemu chjamà simile: XXX- spineY.

U stessu rack cuntene l'equipaggiu di rete per a cunnessione trà i router DC - 2 cù MPLS à bordu. Ma in generale, questi sò i stessi ToRs. Vale à dì, da u puntu di vista di i switch Spine, u ToR abituale cù e macchine cunnesse o un router per DCI ùn importa micca à tuttu - solu invio.

Tali ToR speciali sò chjamati Edge-foglia. Li chjameremu XXX-borduY.

Serà cusì.

In u diagramma di sopra, aghju veramente pusatu bordu è foglia à u listessu livellu. Reti classiche di trè strati Ci anu amparatu à cunsiderà uplinking (da quì u terminu) cum'è uplinks. E quì si trova chì u DCI "uplink" torna in daretu, chì per alcuni rompe ligeramente a logica di solitu. In u casu di grande rete, quandu i centri di dati sò spartuti in unità ancu più chjuche - bul's (Punto di consegna), evidenziate l'individuu Edge-POD's per DCI è accessu à e rete esterne.

Per facilità di percepzioni in u futuru, aghju sempre disegnà Edge over Spine, mentre chì avemu da tene in mente chì ùn ci hè micca intelligenza nantu à Spine è ùn ci sò micca differenze quandu u travagliu cù foglia regulare è Edge-leaf (ancu si pò esse sfumature quì). , ma in generale Questu hè veru).

Schema di una fabbrica cù Edge-leafs.

A trinità di Leaf, Spine è Edge formanu una reta di Underlay o fabbrica.

U compitu di una fabbrica di rete (leghjite Underlay), cum'è avemu digià definitu in ultima questione, assai, assai simplice - per furnisce una cunnessione IP trà e macchine sia in u stessu DC sia trà elli.
Hè per quessa chì a reta hè chjamata fabbrica, cum'è, per esempiu, una fabbrica di commutazione in scatuli di rete modulari, chì pudete leghje più in SDSM14.

In generale, una tale topologia hè chjamata fabbrica, perchè u tissu in traduzzione significa tela. È hè difficiule d'accordu:

A fabbrica hè cumplettamente L3. Nisuna VLAN, senza Broadcast - avemu tali programatori maravigliosi in LAN_DC, sanu cumu scrive applicazioni chì campanu in u paradigma L3, è e macchine virtuali ùn anu micca bisognu di Migrazione Live cù a preservazione di l'indirizzu IP.

È una volta: a risposta à a quistione perchè a fabbrica è perchè L3 hè in un separatu articulu.

DCI - Data Center Interconnect (Inter-DC)

DCI serà urganizatu cù Edge-Leaf, vale à dì, sò u nostru puntu di uscita à l'autostrada.
Per simplicità, assumemu chì i DC sò cunnessi l'un à l'altru da ligami diretti.
Escludemu a cunnessione esterna da cunsiderazione.

Sò cunzignatu chì ogni volta chì sguassate un cumpunente, simplificà significativamente a reta. È quandu avemu automatizatu a nostra reta astratta, tuttu sarà bè, ma nantu à u veru ci sarà crutches.
Questu hè veru. Eppuru, u puntu di sta serie hè di pensà è travaglià nantu à l'approcciu, micca per risolve eroicamente i prublemi imaginarii.

Nant'à Edge-Leafs, u underlay hè situatu in a VPN è trasmessa à traversu a spina MPLS (u stessu ligame direttu).

Questu hè u diagramma di u livellu più altu chì avemu.

Routing

Per u routing in u DC useremu BGP.
Nantu à u troncu MPLS OSPF + LDP.
Per DCI, vale à dì, urganizà a cunnessione in u metro - BGP L3VPN sopra MPLS.

Schema generale di routing

Ùn ci hè micca OSPF o ISIS (protokollu di routing pruibitu in a Federazione Russa) in a fabbrica.

Questu significa chì ùn ci sarà micca Auto-scuperta o calculu di i percorsi più brevi - solu manuale (in realtà automaticu - parlemu di l'automatizazione quì) chì stabilisce u protocolu, u vicinatu è e pulitiche.

Schema di routing BGP in DC

Perchè BGP?

Nantu à questu tema ci hè RFC tutale chjamatu dopu à Facebook è Arista, chì dice cumu custruisce assai grande rete di centri di dati chì utilizanu BGP. Si legge quasi cum'è una fiction, u cunsigliu assai per una serata languida.

È ci hè ancu una sezione sana in u mo articulu dedicata à questu. Induve ti portaraghju è mandu.

Ma ancu, in cortu, nisun IGP hè adattatu per e rete di grandi centri di dati, induve u numeru di dispusitivi di rete hè in millaie.

Inoltre, l'utilizazione di BGP in ogni locu vi permetterà di ùn perde u tempu per sustene parechji protokolli diffirenti è a sincronizazione trà elli.

A manu nantu à u core, in a nostra fabbrica, chì cun un altu gradu di probabilità ùn crecerà micca rapidamente, OSPF seria abbastanza per l'ochji. Quessi sò in realtà i prublemi di megascalers è titani nuvola. Ma imaginemu solu per uni pochi di versioni chì avemu bisognu, è useremu BGP, cum'è Pyotr Lapukhov hà legatu.

Politiche di routing

Nant'à i switch Leaf, impurtate prefissi da l'interfacce di rete Underlay in BGP.
Averemu una sessione BGP trà ognunu una coppia Leaf-Spine, in quale questi prefissi Underlay seranu annunziati nantu à a reta quì è quì.

In un centru di dati, distribuiremu e specificazioni chì avemu impurtatu à ToRe. Nant'à Edge-Leafs, li aggregaremu è li annunceremu à i DC remoti è li manderemu à i TOR. Vale à dì, ogni ToR hà da sapè esattamente cumu per arrivà à un altru ToR in u stessu DC è induve u puntu di entrata hè di ghjunghje à u ToR in un altru DC.

In DCI, e rotte seranu trasmesse cum'è VPNv4. Per fà questu, nantu à Edge-Leaf, l'interfaccia versu a fabbrica serà piazzata in un VRF, chjamemu UNDERLAY, è u vicinatu cù Spine nantu à Edge-Leaf s'alzarà in u VRF, è trà Edge-Leafs in u VPNv4- famiglia.

Avemu ancu pruibitu a re-annunziu di rotte ricevutu da spine daretu à elli.

On Leaf and Spine ùn impurtaremu micca Loopbacks. Avemu solu bisognu di elli à determinà u Router ID.

Ma nantu à Edge-Leafs l'importemu in Global BGP. Trà l'indirizzi Loopback, Edge-Leafs stabiliscerà una sessione BGP in a famiglia VPN IPv4 cù l'altri.

Averemu una spina OSPF + LDP trà i dispositi EDGE. Tuttu hè in una zona. Cunfigurazione estremamente simplice.

Questa hè a stampa cù u routing.

BGP ASN

Edge-Leaf ASN

In Edge-Leafs ci sarà un ASN in tutti i DC. Hè impurtante chì ci hè iBGP trà Edge-Leafs, è ùn avemu micca pigliatu in i sfumaturi di eBGP. Chì sia 65535. In realità, questu puderia esse u numeru di un AS publicu.

Spine ASN

In Spine averemu un ASN per DC. Cuminciamu quì cù u primu numeru da a gamma di AS privati ​​​​- 64512, 64513 E cetara.

Perchè ASN nantu à DC?

Dividemu sta quistione in dui:

• Perchè l'ASN sò listessi in tutte e spine di una DC?
• Perchè sò diffirenti in DC differenti?

Perchè sò i stessi ASN in tutte e spine di una DC?

Eccu ciò chì l'AS-Path di a strada di Underlay nantu à Edge-Leaf serà cusì:
[leafX_ASN, spine_ASN, edge_ASN]
Quandu pruvate d'annunzià torna à Spine, u scacciò perchè u so AS (Spine_AS) hè digià in a lista.

In ogni casu, in u DC simu cumplettamente soddisfatti chì e rotte Underlay chì ascendenu à u Edge ùn puderanu micca falà. Tutte e cumunicazioni trà l'ospiti in u DC deve esse in u livellu di a spina.

In questu casu, i percorsi aggregati di l'altri DC in ogni casu facilmente ghjunghjenu à i ToR - u so AS-Path averà solu ASN 65535 - u numeru di AS Edge-Leafs, perchè hè quì chì sò stati creati.

Perchè sò diffirenti in DC differenti?

In teoria, pudemu avè bisognu di trascinà Loopback è alcune macchine virtuali di serviziu trà DC.

Per esempiu, nant'à l 'ospiti avemu da eseguisce Route Reflector o u listessu VNGW (Virtual Network Gateway), chì chjuderà cù TopR via BGP è annunzià u so loopback, chì deve esse accessibile da tutti i DC.

Dunque, questu hè u so AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

È ùn deve esse micca ASN duplicati in ogni locu.

Vale à dì, Spine_DC1 è Spine_DC2 deve esse diffirenti, cum'è leafX_DC1 è leafY_DC2, chì hè esattamente ciò chì ci avvicinamu.

Cum'è probabilmente sapete, ci sò pirate chì permettenu di accettà rotte cù ASN duplicati malgradu u mecanismu di prevenzione di loop (permette in Cisco). È ancu hà usi legittimi. Ma questu hè una lacuna potenziale in a stabilità di a rete. È personalmente ci sò cascatu un paru di volte.

È s'è no avemu l'uppurtunità di ùn aduprà cose periculose, avemu da prufittà.

Foglia ASN

Averemu un ASN individuale nantu à ogni switch Leaf in tutta a reta.
Facemu questu per i motivi indicati sopra: AS-Path senza loops, cunfigurazione BGP senza bookmarks.

Per chì e rotte trà Leafs passanu bè, l'AS-Path deve esse cusì:
[leafX_ASN, spine_ASN, leafY_ASN]
induve leafX_ASN è leafY_ASN sarianu piacevule per esse sfarenti.

Questu hè ancu necessariu per a situazione cù l'annunziu di un loopback VNF trà DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Adupremu un ASN di 4 byte è u generà basatu annantu à l'ASN di a Spina è u numeru di switch Leaf, vale à dì, cusì: Spine_ASN.0000X.

Questa hè a stampa cù ASN.

pianu IP

In fondu, avemu bisognu di attribuisce indirizzi per e seguenti cunnessione:

1. Indirizzi di rete sottumessi trà ToR è macchina. Deve esse unichi in tutta a reta in modu chì ogni macchina pò cumunicà cù qualsiasi altra. Grande fit 10/8. Per ogni rack ci sò / 26 cù una riserva. Assegnaremu / 19 per DC è / 17 per regione.
2. Indirizzi di ligame trà Leaf/Tor è Spine.

   Vogliu assignà l'algoritmu, vale à dì, calculà da i nomi di i dispositi chì deve esse cunnessi.

   Chì sia... 169.254.0.0/16.
   Vale à dì 169.254.00X.Y/31induve X - Numeru di spine, Y - Rete P2P /31.
   Stu vi permetterà di lanciari sin'à 128 racks, è sin'à 10 Spines in u DC. L'indirizzi di ligami ponu (è seranu) ripetuti da DC à DC.

3. Organizemu a junction Spine-Edge-Leaf in subnets 169.254.10X.Y/31, induve esattamente u listessu X - Numeru di spine, Y - Rete P2P /31.
4. Ligami indirizzi da Edge-Leaf à MPLS backbone. Quì a situazione hè un pocu sfarente - u locu induve tutti i pezzi sò cunnessi in una sola torta, cusì riutilizà i stessi indirizzi ùn funziona micca - avete bisognu di selezziunà a prossima subnet libera. Dunque, andemu à piglià cum'è una basa 192.168.0.0/16 è noi razzieremu i liberi da ellu.
5. Indirizzi Loopback. Daremu tutta a gamma per elli 172.16.0.0/12.
   • Leaf - /25 per DC - i stessi 128 racks. Assegnaremu /23 per regione.
   • Spine - /28 per DC - finu à 16 Spine. Attribuemu / 26 per regione.
   • Edge-Leaf - /29 per DC - finu à 8 scatuli. Attribuemu / 27 per regione.

Se ùn avemu micca abbastanza spazii assignati in u DC (è ùn ci sarà micca - dicemu di esse iperscalers), simpricimenti selezziunate u prossimu blocu.

Questa hè a stampa cù l'indirizzu IP.

Loopbacks:

Prefissu
U rolu di u dispusitivu
Situazione
ДЦ

172.16.0.0/23
arice
 
 

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
sia

172.16.2.0/23
head
 
 

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
sia

172.16.8.0/21
foglia
 
 

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
sia

Sottuttu:

Prefissu
Situazione
ДЦ

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
sia

Laba

Dui venditori. Una reta. ADSM.

Juniper + Arista. Ubuntu. Bona vechja Eve.

A quantità di risorse in u nostru servitore virtuale in Mirana hè sempre limitata, cusì per a pratica useremu una reta simplificata à u limitu.

Dui centri di dati: Kazan è Barcelona.

• Dui spine ognunu: Juniper è Arista.
• Un toru (Foglia) in ognunu - Juniper è Arista, cù un òspite cunnessu (pigliemu un Cisco IOL ligeru per questu).
• Un nodu Edge-Leaf ognunu (per avà solu Juniper).
• Un switch Cisco per guvernà tutti.
• In più di e scatuli di rete, una macchina di cuntrollu virtuale hè in esecuzione. Esecuzione di Ubuntu.
  Hà accessu à tutti i dispositi, eseguirà sistemi IPAM / DCIM, una mansa di script Python, Ansible è tuttu ciò chì pudemu avè bisognu.

Cunfigurazione cumpleta di tutti i dispusitivi di rete, chì avemu da pruvà à ripruduce cù l'automatizazione.

cunchiusioni

Hè ancu accettatu? Deve scrive una breve cunclusione sottu à ogni articulu?

Allora avemu sceltu à trè livelli A reta di Kloz in u DC, postu chì aspittemu assai trafficu Est-Ovest è vulemu ECMP.

A reta hè stata divisa in fisica (underlay) è virtuale (overlay). À u listessu tempu, u overlay principia da l'ospitu - simplifichendu cusì i requisiti per u sottu.

Avemu sceltu BGP cum'è u protocolu di routing per e rete di rete per a so scalabilità è a flessibilità di pulitica.

Averemu nodi separati per urganizà DCI - Edge-leaf.
A spina avarà OSPF + LDP.
DCI serà implementatu basatu annantu à MPLS L3VPN.
Per i ligami P2P, calculeremu l'indirizzi IP in modu algoritmicu basatu annantu à i nomi di i dispositi.
Assignaremu i loopbacks secondu u rolu di i dispositi è a so situazione sequenziale.
Prefissi di Underlay - solu nantu à i switch Leaf in sequenza basatu nantu à a so situazione.

Assumimu chì avà ùn avemu micca l'equipaggiu installatu.
Dunque, i nostri prossimi passi seranu aghjunghje à i sistemi (IPAM, inventariu), urganizà l'accessu, generà una cunfigurazione è implementà.

In u prossimu articulu avemu da trattà Netbox - un inventariu è sistema di gestione per u spaziu IP in un DC.

Grazie

• Andrey Glazkov alias @glazgoo per correzzione è correzioni
• Alexander Klimenko alias @v00lk per a correzione è e modifiche
• Artyom Chernobay per KDPV

Source: www.habr.com