Nei primi due articoli ho sollevato il tema dell'automazione e delineato il suo framework, mentre nel secondo ho fatto un'escursione nella virtualizzazione della rete, come primo approccio all'automazione della configurazione dei servizi.
E ora è arrivato il momento di disegnare lo schema della rete fisica.

Se non hai una buona familiarità con i dispositivi delle reti dei data center, ti consiglio vivamente di iniziare con questo articolo su di loro.

Tutti i numeri:

• 0. ADMS. Parte Zero. Pianificazione
• 1. ADMS. Prima Parte (quella dopo lo zero). Virtualizzazione della rete
• 2. ADMS. Parte Seconda. Progettazione della rete

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

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

In questo caso, avremo uno scenario relativamente semplice per l'automazione, poiché disponiamo di molte macchine che si configurano allo stesso modo.

Sceglieremo un data center sferico nel vuoto:

• Una versione del design ovunque.
• Due fornitori che formano due piani di rete.
• Un data center è simile a un altro come due gocce d'acqua.

Contenuto

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

Supponiamo che il nostro Service Provider LAN_DC ospiti, ad esempio, video formativi sulla sopravvivenza in ascensori bloccati.

Nelle megalopoli, questo è estremamente popolare, quindi ci vogliono molte macchine fisiche.

Inizialmente, descriverò la rete approssimativamente così come la si vorrebbe vedere. Poi semplificherò per il laboratorio.

Topologia fisica

Location

LAN_DC avrà 6 data center:

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

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

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

Dentro il DC (Intra-DC)

In tutti i DC ci sono reti identiche di connettività interna, basate sulla topologia Clos.
Cosa sono le reti Clos e perché sono così una sezione separata articolo.

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

In ogni rack ci sono 30 macchine. Queste non ci interesseranno.

In ogni rack c'è uno switch a cui sono collegate tutte le macchine — questo è Top of the Rack switch — ToR oppure in termini della fabbrica Clos, lo chiameremo Leaf.

Schema generale della fabbrica.

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

Nei miei articoli mi permetterò di usare liberamente i termini Leaf e ToR come sinonimi. Tuttavia, è importante ricordare che non è così.
ToR è uno switch installato nel rack a cui si collegano le macchine.
Leaf è il ruolo del dispositivo nella rete fisica o uno switch di primo livello nei termini della topologia Clos.
Cioè, Leaf != ToR.
Quindi un Leaf può essere ad esempio uno switch EndofRow.
Tuttavia, in questo articolo ci riferiremo comunque ai termini come sinonimi.

Ogni switch ToR è a sua volta collegato a quattro switch aggregatori di livello superiore — Spine. Per gli Spine è stato riservato uno rack nel DC. Li designeremo in modo analogo: XXX-spineY.

In the same rack, there will be networking equipment for connectivity between data centers — 2 routers with MPLS onboard. But essentially, they are the same ToRs. From the perspective of Spine switches, it doesn’t matter whether it’s a regular ToR with connected machines or a router for DCI — it forwards in the same way.

Such special ToRs are called Edge-leaf. We will refer to them as XXX-edgeY.

This is how it will look.

In the diagram above, I indeed placed the edge and leaf at the same level. Classic three-tier networks have trained us to view uplinks (hence the term) as links upwards. But here, the DCI 'uplink' actually goes back down, which can somewhat disrupt the usual logic. In large networks, when data centers are divided into smaller units — PODS‘ (Point Of Delivery), separate Edge-PODsfor DCI and external network access are highlighted.

For clarity in future illustrations, I will still draw Edge above Spine, while keeping in mind that there is no intelligence on Spine and no distinctions in operation between regular Leaf and Edge-leaf (though there may be nuances, but overall this is the case).

Fabric diagram with Edge-leafs.

I nodi Leaf, Spine ed Edge formano una rete Underlay o una fabbrica.

Il compito della rete fabbrica (leggi Underlay), come abbiamo già stabilito in nella versione precedente, è molto e molto semplice: garantire la connettività IP tra le macchine sia all'interno di un singolo data center, sia tra essi.
Ecco perché la rete viene chiamata fabbrica, proprio come ad esempio la fabbrica di commutazione all'interno delle scatole di rete modulari, di cui si può leggere di più in SDM14.

In effetti, tale topologia è chiamata fabbrica perché 'fabric' in traduzione significa 'tessuto'. Ed è difficile non essere d'accordo:

La fabbrica è completamente L3. Niente VLAN, niente Broadcast — i nostri meravigliosi programmatori in LAN_DC sanno scrivere applicazioni che operano nella filosofia L3, e le macchine virtuali non richiedono Live Migration con il mantenimento dell'indirizzo IP.

E ancora una volta: la risposta alla domanda sul perché fabbrica e perché L3 si trova in un articolo.

DCI — Data Center Interconnect (Inter-DC)

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

Sono consapevole che ogni volta che rimuovo un componente, semplifico notevolmente la rete. E con l'automazione della nostra rete astratta andrà tutto bene, mentre nella realtà ci saranno delle soluzioni di fortuna.
È vero. Eppure, l'obiettivo di questa serie è riflettere e lavorare su approcci, piuttosto che affrontare eroicamente problemi inventati.

Sugli Edge-Leaf, l'underlay è collocato nel VPN e trasmesso tramite il backbone MPLS (il link diretto).

Ecco come appare uno schema di alto livello.

Routing

Per la routing all'interno del data center utilizzeremo BGP.
Sul backbone MPLS OSPF+LDP.
Per DCI, ovvero l'organizzazione della connettività nell'underlay — BGP L3VPN over MPLS.

Schema generale di routing.

In fabbrica non ci saranno OSPF e ISIS (protocollo di routing vietato nella Federazione Russa).

Ciò significa che non ci sarà Auto-discovery e calcolo dei percorsi più brevi — solo configurazione manuale (in realtà automatica, visto che parliamo di automazione) del protocollo, dei vicinati e delle politiche.

Schema di routing BGP all'interno del data center.

Perché BGP?

Su questo argomento ci sono interi RFC di Facebook e Arista, dove si spiega come costruire sistemi molto grandi. reti dei data center, utilizzando BGP. Si legge quasi come un'opera d'arte, lo consiglio vivamente per una serata rilassata.

Inoltre, c'è un'intera sezione nel mio articolo dedicata a questo. A cui vi rimando.

Tuttavia, in breve, nessun IGP è adatto per le reti dei grandi data center, dove il numero di dispositivi di rete arriva a migliaia.

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

A cuore aperto, nella nostra fabbrica, che con molta probabilità non crescerà rapidamente, basterebbe OSPF. Questo è davvero un problema per i megascale e i giganti del cloud. Ma fantasiamo solo per alcuni numeri, che ci serve, e utilizzeremo BGP, come ha lasciato in eredità Petr Lapukhov.

Politiche di instradamento

Sui Leaf switch importiamo in BGP i prefissi da interfacce Underlay con le reti.
Avremo una sessione BGP tra ogni coppia Leaf-Spine, in cui questi prefissi Underlay saranno annunciati attraverso la rete.

All'interno di un data center, distribuiremo specifiche importate su TOR. Le aggregheremo sugli Edge-Leaf e le annunceremo nei DC remoti, portandole ai TOR. Ogni TOR conoscerà esattamente come raggiungere un altro TOR all'interno dello stesso DC e dove si trova il punto di ingresso per accedere a un TOR in un diverso DC.

In DCI, i percorsi saranno trasmessi come VPNv4. A tal fine, sull'interfaccia Edge-Leaf verso la fabbrica, sarà inserita in VRF, che chiameremo UNDERLAY, e la vicinanza con Spine su Edge-Leaf sarà attivata all'interno del VRF, mentre tra gli Edge-Leaf in famiglia VPNv4.

Inoltre, vietiamo il reannuncio dei percorsi ricevuti dagli spine, tornando a loro.

Su Leaf e Spine non importeremo le Loopback. Ci serviranno solo per determinare il Router ID.

Tuttavia, sugli Edge-Leaf importeremo in Global BGP. Tra gli indirizzi Loopback, gli Edge-Leaf stabiliranno una sessione BGP in IPv4 VPN-family tra di loro.

Tra i dispositivi EDGE, avremo un backbone esteso su OSPF+LDP. Tutto in un'unica zona. Configurazione estremamente semplice.

Questa è la situazione della routizzazione.

BGP ASN

Edge-Leaf ASN

Sugli Edge-Leaf ci sarà un solo ASN in tutti i DC. È importante che ci sia iBGP tra gli Edge-Leaf, per evitare problemi con eBGP. Utilizziamo 65535. In realtà, potrebbe essere un numero AS pubblico.

ASN Spine

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

Perché ASN per DC?

Scomponiamo questa questione in due parti:

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

Perché ASN identici su tutti gli spine di un DC

Ecco come apparirà il percorso AS del routing Underlay sugli Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Quando si prova ad annunciare nuovamente su Spine, esso verrà scartato perché il suo AS (Spine_AS) è già presente nell'elenco.

Tuttavia, all'interno del DC ci sta bene che i percorsi Underlay che sono saliti fino agli Edge non possano scendere. Tutta la comunicazione tra gli host all'interno del DC deve avvenire a livello degli spine.

Comunque, i percorsi aggregati di altri DC arriveranno senza problemi ai ToR — nel loro AS-Path ci sarà solo ASN 65535 — il numero AS degli Edge-Leaf, perché su di essi sono stati creati.

Perché diversi in diversi DC

Teoricamente potremmo dover far passare dei Loopback di alcune macchine virtuali di servizio tra i DC.

Ad esempio, su un host avremo in esecuzione un Route Reflector oppure quello stesso VNGW (Virtual Network Gateway), che si connetterà via BGP con il ToR e annuncerà il suo loopback, che deve 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 dovrebbero esserci ASN ripetuti.

Cioè, Spine_DC1 e Spine_DC2 devono essere diversi, così come leafX_DC1 e leafY_DC2, il che ci porta proprio a questo punto.

Come probabilmente saprete, esistono hack che consentono di accettare percorsi con ASN ripetuti nonostante il meccanismo di prevenzione dei cicli (allowas-in su Cisco). E ci sono anche applicazioni del tutto legittime per questo. Ma rappresenta 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 cose pericolose, ne approfitteremo.

Leaf ASN

Avremo un ASN unico su ciascun switch Leaf nell'intera rete.
Lo facciamo per motivi già esposti: AS-Path senza cicli, 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 leafX_ASN e leafY_ASN sarebbe meglio che fossero diversi.

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

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

Ecco come si presenta la situazione con l'ASN.

Piano IP

Fondamentalmente, abbiamo bisogno di allocare gli indirizzi per le seguenti connessioni:

1. Gli indirizzi della rete Underlay tra ToR e macchina. Devono essere unici all'interno dell'intera rete, affinché ogni macchina possa comunicare con qualsiasi altra. È perfetto 10/8. Per ogni rack abbiamo bisogno di /26 come riserva. Allocando /19 per i DC e /17 per la regione.
2. Indirizzi di collegamento tra Leaf/Tor e Spine.

   Vorremmo assegnarli in modo algoritmico, ovvero calcolando dai nomi dei dispositivi da connettere.

   Diciamo che sia… 169.254.0.0/16.
   E precisamente 169.254.00X.Y/31, dove X — numero dello Spine, Y — rete P2P /31.
   Questo permetterà di avviare fino a 128 rack, e fino a 10 Spine nei DC. Gli indirizzi di collegamento possono (e verranno) ripetuti da DC a DC.

3. Organizzeremo il collegamento Spine — Edge-Leaf su sottoreti 169.254.10X.Y/31, dove allo stesso modo X — numero dello Spine, Y — rete P2P /31.
4. Indirizzi di collegamento da Edge-Leaf alla dorsale MPLS. Qui la situazione è un po' diversa: il punto in cui tutti i pezzi si uniscono in un'unica soluzione, quindi non si possono riutilizzare gli stessi indirizzi: bisogna scegliere la prossima sottorete libera. Quindi prenderemo come base 192.168.0.0/16 e ne estrarremo gli indirizzi disponibili.
5. Indirizzi Loopback. Diamo loro l'intero intervallo 172.16.0.0/12.
   • Leaf — /25 per il DC — le stesse 128 rack. Riserviamo /23 per la regione.
   • Spine — /28 per il DC — fino a 16 Spine. Riserviamo /26 per la regione.
   • Edge-Leaf — /29 per il DC — fino a 8 unità. Riserviamo /27 per la regione.

Se nel DC non avremo abbastanza intervalli riservati (e non ne avremo — aspiriamo alla scalabilità iperscalare), semplicemente riserviamo il blocco successivo.

Ecco com'è la situazione con l'assegnazione degli indirizzi IP.

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

Laboratorio

Due fornitori. Una rete. ADSTM.

Juniper + Arista. Ubuntu. La vecchia cara Eva.

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

Due data center: Kazan e Barcellona.

• Due spine in ognuno: Juniper e Arista.
• Un Leaf in ogni torre — Juniper e Arista, con un host connesso (utilizzeremo un leggero Cisco IOL per questo).
• Una node Edge-Leaf (al momento solo Juniper).
• Un switch Cisco per governarli tutti.
• Oltre alle scatole di rete, è stata avviata una macchina virtuale di gestione. Sotto Ubuntu.
  Ha accesso a tutti i dispositivi, su di essa gireranno sistemi IPAM/DCIM, un insieme di script in Python, Ansible e qualsiasi altra cosa ci serva.

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

Conclusione

È consuetudine? Fare un breve riepilogo sotto ogni articolo?

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

Abbiamo diviso la rete in fisica (underlay) e virtuale (overlay). L'overlay inizia dall'host, semplificando così i requisiti per l'underlay.

Abbiamo scelto BGP come protocollo di routing delle reti underlay per la sua scalabilità e flessibilità delle politiche.

Avremo nodi separati per organizzare DCI — Edge-leaf.
La dorsale utilizzerà OSPF+LDP.
DCI sarà implementato basato su MPLS L3VPN.
Per i link P2P degli indirizzi IP, calcoleremo algoritmicamente in base ai nomi dei dispositivi.
Assegneremo i loopback in base al ruolo dei dispositivi e alla loro posizione in sequenza.
I prefissi sottostanti saranno assegnati solo ai Leaf switch sequentialmente in base alla loro posizione.

Supponiamo che attualmente non abbiamo attrezzature installate.
Pertanto, i nostri prossimi passi saranno: registrarli nei sistemi (IPAM, inventario), organizzare l'accesso, generare la configurazione e implementarla.

Nell'articolo successivo, esploreremo Netbox, un sistema di inventario e gestione dello spazio IP nei data center.

Grazie

• Ad Andrey Glazkov aka @glazgoo per la revisione e le correzioni
• Ad Alexander Klimenko aka @v00lk per la revisione e le correzioni
• A Artem Chernobay per KDPV

Fonte: habr.com