Nei primi due articoli ho sollevato la questione dell'automazione e abbozzato il suo framework, nel secondo ho fatto una digressione sulla virtualizzazione della rete, come primo approccio all'automazione della configurazione dei servizi.
E ora è tempo di disegnare lo schema della rete fisica.

Se non hai familiarità con i dispositivi delle reti dei data center, ti consiglio vivamente di iniziare da un articolo al riguardo.

Tutti gli episodi:

• 0. AD DSM. Parte Zero. Pianificazione
• 1. AD DSM. Parte Prima (quella dopo la zero). Virtualizzazione della rete
• 2. AD DSM. Parte Seconda. Design della rete

Le pratiche descritte in questa serie dovrebbero essere applicabili a reti di qualsiasi tipo, dimensione e varietà di fornitori (o no). Tuttavia, non è possibile descrivere un esempio universale di applicazione di questi approcci. Pertanto, mi concentrerò sull'architettura moderna della rete del DC: Fabric Clos.
DCI verrà realizzato su MPLS L3VPN.

Sopra la rete fisica opera una rete Overlay dal host (questo può essere VXLAN di OpenStack o Tungsten Fabric o qualsiasi altra cosa che richieda alla rete solo una connettività IP di base).

In questo caso si otterrà uno scenario relativamente semplice per l'automazione, perché abbiamo molto hardware che si configura allo stesso modo.

Sceglieremo un DC sferico nel vuoto:

• Una versione del design ovunque.
• Due fornitori che formano due piani della rete.
• Un DC somiglia a un altro come due gocce d'acqua.

Contenuto

• Topologia fisica
• Routing
• Piano IP
• Lab
• Conclusione
• Link utili

Immagina che il nostro Fornitore di Servizio LAN_DC ospiti, per esempio, video formativi sulla sopravvivenza in ascensori bloccati.

Nei megalopoli questo è di un successo straordinario, quindi ci sono molte macchine fisiche necessarie.

Prima descriverò la rete approssimativamente come la si vorrebbe vedere. E poi la semplificherò per il lab.

Topologia fisica

Località

LAN_DC avrà 6 DC:

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

• Spagna (SP):
  • Barcellona (bcn)
  • Malaga (mlg)

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

All'interno del DC (Intra-DC)

In tutti i DC ci sono reti identiche di connettività interna, basate sulla topologia Clos.
Che cos'è la rete Clos e perché proprio essa — in un articolo separato abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer..

In ogni DC ci sono 10 rack con macchine, saranno numerati come A, B, C E così via.

In ogni rack ci sono 30 macchine. Non ci interesseranno.

Inoltre, in ogni rack c'è uno switch, a cui sono collegate tutte le macchine — questo è Top of the Rack switch — ToR o altrimenti in termini di Fabric Clos lo chiameremo Leaf.

Schema generale della fabbrica.

Li chiameremo XXX-leafY, dove XXX — abbreviazione di tre lettere DC, e Y — numero di serie. Ad esempio, kzn-leaf11.

Negli articoli mi permetterò di utilizzare piuttosto liberamente i termini Leaf e ToR come sinonimi. Tuttavia, è importante ricordare che non è così.
ToR è uno switch montato su rack a cui sono collegate le macchine.
Leaf è il ruolo di un dispositivo nella rete fisica o uno switch di primo livello in termini di topologia Clos.
Cioè Leaf != ToR.
Quindi un Leaf può essere anche uno switch EndofRaw, per esempio.
Tuttavia, nel contesto di questo articolo, ci riferiremo comunque a essi come sinonimi.

Ogni switch ToR è collegato a quattro switch aggregatori superiori — Spine. A ciascun Spine è assegnato un rack nel DC. Lo nomineremo in modo analogo: XXX-spineY.

Nello stesso rack ci sarà l'attrezzatura di rete per la connettività tra i DC — 2 router con MPLS a bordo. Ma in sostanza, sono gli stessi ToR. Cioè, dal punto di vista degli switch Spine, non ha alcuna importanza un normale ToR con macchine collegate o un router per DCI — è comunque importante fare forwarding.

Questi switch ToR speciali vengono chiamati Edge-leaf. Li chiameremo XXX-edgeY.

Sarà così.

Nello schema sopra, edge e leaf sono realmente posizionati allo stesso livello. Le reti classiche a tre livelli ci hanno insegnato a considerare l'uplink (da qui il termine) come link verso l'alto. Qui, però, l'«uplink» DCI va verso il basso, il che rompe un po' la logica abituale. Nel caso di grandi reti, quando i data center sono ulteriormente suddivisi in unità più piccole — POD‘e (Point Of Delivery), vengono allocati dei Edge-POD‘e per DCI e per l'accesso a reti esterne.

Per una migliore comprensione in futuro, disegnerò comunque l'Edge sopra lo Spine, tenendo presente che non vi è alcuna intelligenza su Spine e nessuna differenza nel funzionamento tra normali Leaf e Edge-leaf (anche se potrebbero esserci delle sfumature, ma in generale è così).

Schema della fabbrica con Edge-leaf.

La triade Leaf, Spine ed Edge forma la rete Underlay o la fabbrica.

L'obiettivo della fabbrica di rete (leggi Underlay), come abbiamo già definito in versione precedente, è molto semplice: garantire la connettività IP tra le macchine sia all'interno di un DC sia tra di essi.
Ecco perché la rete si chiama fabbrica, proprio come una fabbrica di commutazione all'interno di scatole di rete modulari, di cui si può leggere di più in CSM14.

In effetti, questa topologia si chiama fabbrica, perché il termine fabric in italiano significa tessuto. E non si può non essere d'accordo:

La fabbrica è completamente L3. Nessun VLAN, nessun Broadcast: i nostri straordinari programmatori di LAN_DC sanno scrivere applicazioni che operano nella paradigmaticità di L3, e le macchine virtuali non necessitano di Live Migration mantenendo l'indirizzo IP.

E ancora una volta: la risposta alla domanda perché fabbrica e perché L3 si trova in una sezione separata. abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer..

DCI - Data Center Interconnect (Inter-DC)

Il DCI sarà organizzato utilizzando Edge-Leaf, cioè essi sono il nostro punto di uscita verso la dorsale.
Per semplicità, supponiamo che i data center siano collegati tra loro tramite link diretti.
Escludiamo dalla considerazione la connettività esterna.

Sono consapevole che ogni volta che rimuovo un componente, semplifico notevolmente la rete. E nella automazione della nostra rete astratta andrà tutto bene, ma nella realtà appariranno problemi.
È così. Eppure, lo scopo di questa serie è riflettere e lavorare sugli approcci, non risolvere eroicamente problemi inventati.

Sugli Edge-Leaf, l'underlay è inserito in VPN e trasmesso attraverso la dorsale MPLS (quello stesso link diretto).

Questa è l'immagine generale risultante.

Routing

Per il routing all'interno del data center utilizzeremo BGP.
Sulla dorsale MPLS OSPF+LDP.
Per DCI, ovvero per organizzare la connettività nell'underlay - BGP L3VPN su MPLS.

Schema generale di routing

Nella fabbrica non ci sono OSPF né ISIS (protocollo di routing vietato nella Federazione Russa).

E questo significa che non ci sarà Auto-discovery e calcolo dei percorsi più brevi - solo configurazione manuale (in realtà automatica - stiamo parlando di automazione) del protocollo, delle vicinanze e delle politiche.

Schema di routing BGP all'interno del DC

Perché BGP?

C'è un intero RFC a nome di Facebook e Arista, che illustra come costruire reti molto grandi di data center utilizzando BGP. Si legge quasi come un romanzo, lo consiglio vivamente per una serata tranquilla.

E c'è anche un intero capitolo del mio articolo dedicato a questo. E vi rimando.

Tuttavia, se dobbiamo riassumere, nessun IGP è adatto per le reti di grandi data center, dove il numero dei dispositivi di rete è nell'ordine delle migliaia.

Inoltre, l'uso del BGP ovunque consentirà di non disperdersi nel supporto di più protocolli diversi e nella sincronizzazione tra di essi.

Parlando con sincerità, nella nostra fabbrica, che molto probabilmente non crescerà rapidamente, basterebbe anche l'OSPF. Questi sono in realtà problemi dei mega-scalatori e dei titani del cloud. Ma fantastichiamo solo per qualche edizione sul fatto che ne abbiamo bisogno e utilizziamo BGP, come ha lasciato in eredità Pyotr Lapukhov.

Politiche di routing

Sugli switch Leaf importiamo in BGP i prefissi dalle interfacce Underlay con le reti.
Avremo una sessione BGP tra ogni coppia Leaf-Spine, in cui questi prefissi Underlay verranno annunciati nella rete in entrambi i sensi.

All'interno di un data center, diffonderemo le specifiche che abbiamo importato sui ToR. Sugli Edge-Leaf le aggregheremo e le annunceremo ai DC remoti e le ridurremo fino ai ToR. Questo significa che ogni ToR saprà esattamente come arrivare a un altro ToR in questo stesso DC e dove si trova il punto di ingresso per raggiungere un ToR in un altro DC.

Nella DCI, le rotte verranno trasmesse come VPNv4. Per questo, sull'interfaccia Edge-Leaf verso la fabbrica verrà posizionata in un VRF, chiamiamolo UNDERLAY, e la vicinanza con lo Spine sull'Edge-Leaf sarà attivata all'interno del VRF, mentre tra gli Edge-Leaf nella VPNv4-family.

Inoltre, vietiamo di rinunciare a rotte ricevute dagli spine, riannunciandole su di essi.

Sugli Switch Leaf e Spine non importeremo i Loopback. Ci serviranno solo per determinare l'Router ID.

Ma sugli Edge-Leaf importiamo il Loopback nel BGP Globale. Tra gli indirizzi Loopback, gli Edge-Leaf stabiliranno una sessione BGP nella famiglia VPN IPv4 tra di loro.

Tra i dispositivi EDGE avremo un backbone esteso su OSPF+LDP. Tutto in una sola zona. Configurazione estremamente semplice.

Questa è la situazione con il routing.

BGP ASN

Edge-Leaf ASN

Sugli Edge-Leaf ci sarà un ASN in tutti i DC. È importante che tra Edge-Leaf vi sia iBGP, così non ci imbatteremo in sfide di eBGP. Sarà 65535. In realtà potrebbe essere il numero di AS pubblico.

Spine ASN

Sullo Spine avremo un ASN per DC. Iniziamo con il primo numero dell'intervallo degli AS privati — 64512, 64513 e così via.

Perché ASN in DC?

Decomponiamo questa domanda in due:

• Perché ASN identici su tutti gli spine di un DC?
• Perché diversi in DC diversi?

Perché ASN identici su tutti gli spine di un DC

Ecco come apparirà l'AS-Path della rotta Underlay sugli Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Nel tentativo di rinunciare a riannunciarla di nuovo allo Spine, lo stesso la respingerà perché il suo AS (Spine_AS) è già presente nell'elenco.

Tuttavia, all'interno del DC siamo completamente soddisfatti del fatto che i percorsi Underlay, che si sono elevati fino all'Edge, non possano scendere. Tutta la comunicazione tra gli host all'interno del DC deve avvenire a livello di spine.

In ogni caso, i percorsi aggregati degli altri DC raggiungeranno senza ostacoli i ToR — nel loro AS-Path ci sarà solo l'ASN 65535 — numero AS degli Edge-Leaf, poiché è proprio su di essi che sono stati creati.

Perché diversi in diversi DC

Teoricamente potremmo aver bisogno di trasferire i Loopback di qualche macchina virtuale di servizio tra DC.

Ad esempio, su un host avremo in esecuzione un Route Reflector o quello specifico VNGW (Virtual Network Gateway), che tramite BGP si collegherà al ToR e annuncerà il suo loopback, che dovrà essere accessibile da tutti i DC.

Ecco come apparirà il suo AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

E qui non devono esserci ASN ripetuti.

Cioè, Spine_DC1 e Spine_DC2 devono essere diversi, così come leafX_DC1 e leafY_DC2, con cui ci stiamo avvicinando.

Come probabilmente sapete, esistono hack che permettono di accettare percorsi con ASN ripetuti, contrariamente al meccanismo di prevenzione dei loop (allowas-in su Cisco). E questo ha anche applicazioni legittime. Ma è una potenziale falla nella stabilità della rete. E personalmente ci sono già inciampato un paio di volte.

E se abbiamo la possibilità di non utilizzare elementi pericolosi, ne approfitteremo.

Leaf ASN

Avremo un ASN individuale su ogni switch Leaf all'interno dell'intera rete.
Facciamo così per motivi riportati sopra: AS-Path senza loop, configurazione BGP senza backdoor.

Affinché i percorsi tra i Leaf passino senza ostacoli, l'AS-Path deve apparire così:
[leafX_ASN, spine_ASN, leafY_ASN]
dove è preferibile che leafX_ASN e leafY_ASN siano diversi.

Questo è necessario anche per la situazione di annuncio del loopback VNF tra DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Useremo un ASN a 4 byte e lo genereremo sulla base dell'ASN del Spine e del numero del Leaf switch, precisamente in questo modo: Spine_ASN.0000X.

Ecco come si presenta il quadro con l'ASN.

Piano IP

In linea di principio, dobbiamo riservare indirizzi per le seguenti connessioni:

1. Indirizzi di rete Underlay tra ToR e macchina. Devono essere unici all'interno dell'intera rete, affinché ogni macchina possa contattare qualsiasi altra. Ottimo per 10/8. Per ogni rack ci saranno riservati /26 con margine. Riserviamo /19 per il DC e /17 per la regione.
2. Indirizzi di collegamento tra Leaf/Tor e Spine.

   Vorremmo assegnarli in modo algoritmico, cioè calcolandoli dai nomi dei dispositivi da collegare.

   Facciamo che sia… 169.254.0.0/16.
   Vale a dire 169.254.00X.Y/31, dove X — numero Spine, Y — rete P2P /31.
   Questo permetterà di avviare fino a 128 rack e fino a 10 Spine nel DC. Gli indirizzi di collegamento possono (e saranno) ripetuti da DC a DC.

3. Collegheremo Spine ed Edge-Leaf su sottoreti 169.254.10X.Y/31, dove esattamente allo stesso modo X — numero Spine, Y — rete P2P /31.
4. Gli indirizzi di collegamento da Edge-Leaf alla dorsale MPLS. Qui la situazione è un po' diversa: è il punto di connessione di tutti i pezzi in un'unica torta, quindi non sarà possibile riutilizzare gli stessi indirizzi: bisogna scegliere la prossima sottorete libera. Pertanto adotteremo 192.168.0.0/16 e ne estrarremo indirizzi liberi.
5. Indirizzi Loopback. Dedicheremo a loro l'intero intervallo 172.16.0.0/12.
   • Leaf — per /25 nel DC — gli stessi 128 rack. Assegneremo /23 per la regione.
   • Spine — per /28 nel DC — fino a 16 Spine. Assegneremo /26 per la regione.
   • Edge-Leaf — per /29 nel DC — fino a 8 scatole. Assegneremo /27 per la regione.

Se nel DC non avremo sufficiente intervalli assegnati (e non ne avremo — stiamo puntando a un'iper-scalabilità), semplicemente assegneremo il blocco successivo.

Ecco come si presenta la situazione con l'IP addressing.

Loopback:

Prefisso
Ruolo del dispositivo
Regione
DC

172.16.0.0/23
edge
 
 

172.16.0.0/27
it
 

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
spine
 
 

172.16.2.0/26
it
 

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
leaf
 
 

172.16.8.0/23
it
 

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

Underlay:

Prefisso
Regione
DC

10.0.0.0/17
it
 

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

Lab

Due fornitori. Una rete. ADSM.

Juniper + Arista. Ubuntu. La vecchia buona Eva.

Il numero di risorse sulla nostra virtual machine in Mirano è comunque limitato, quindi per la pratica utilizzeremo una rete semplificata al massimo.

Due data center: Kazan e Barcellona.

• Due spine in ciascuno: Juniper e Arista.
• Un Leaf in ciascuno — Juniper e Arista, con un host collegato (usiamo un leggera Cisco IOL per questo).
• Una nodi Edge-Leaf (solo Juniper per ora).
• Un switch Cisco per governarli tutti.
• Oltre alle scatole di rete, è stata avviata una macchina virtuale di gestione. Sotto il controllo di Ubuntu.
  Essa ha accesso a tutti i dispositivi, su di essa gireranno i sistemi IPAM/DCIM, un bouquet di script Python, Ansible e qualsiasi altra cosa ci possa servire.

Configurazione completa di tutti i dispositivi di rete, che cercheremo di riprodurre tramite automazione.

Conclusione

È così che si fa? Scrivere un breve riassunto sotto ogni articolo?

Quindi abbiamo scelto una rete a tre livelli di Clos all'interno del DC, poiché ci aspettiamo molto traffico East-West e vogliamo ECMP.

Abbiamo diviso la rete in fisica (underlay) e virtuale (overlay). In questo modo l'overlay inizia dall'host, semplificando i requisiti per l'underlay.

Abbiamo scelto BGP come protocollo per il routing delle reti a banda larga per la sua scalabilità e flessibilità delle politiche.

Avremo nodi separati per organizzare il DCI — Edge-leaf.
Sulla dorsale ci saranno OSPF+LDP.
Il DCI sarà implementato su base MPLS L3VPN.
Per i link P2P, gli indirizzi IP saranno calcolati algoritmicamente in base ai nomi dei dispositivi.
Gli loopback saranno assegnati in base al ruolo dei dispositivi e alla loro posizione in modo sequenziale.
I prefissi di sottorete — solo su switch Leaf in modo sequenziale in base alla loro posizione.

Supponiamo che al momento non abbiamo ancora installato l'hardware.
Quindi i nostri prossimi passi saranno: registrarli nei sistemi (IPAM, inventario), organizzare l'accesso, generare la configurazione e implementarla.

Nel prossimo articolo ci concentreremo su Netbox — un sistema di inventario e gestione dello spazio IP nei DC.

Grazie a

• Ad Andrey Glaskov aka @glazgoo per la revisione e le correzioni
• Ad Alexander Klimenko aka @v00lk per la revisione e le correzioni
• Ad Artyom Chernobaev per il feedback

Fonte: habr.com