Nei primi due articoli ho sollevato la questione dell'automazione e ne ho delineato il quadro, nel secondo mi sono ritirato nella virtualizzazione della rete, come primo approccio all'automazione della configurazione dei servizi.
Ora è il momento di disegnare uno schema della rete fisica.

Se non hai familiarità con la configurazione delle reti di data center, ti consiglio vivamente di iniziare con articoli su di loro.

Tutti i problemi:

• 0.ADSM. Parte Zero. Pianificazione
• 1. ADSM. Prima parte (che è dopo lo zero). Virtualizzazione della rete
• 2. ADSM. Seconda parte. Progettazione della rete

Le pratiche descritte in questa serie dovrebbero essere applicabili a qualsiasi tipo di rete, di qualsiasi dimensione, con qualsiasi varietà di fornitori (non). Tuttavia, è impossibile descrivere un esempio universale dell’applicazione di questi approcci. Pertanto, mi concentrerò sulla moderna architettura della rete DC: Fabbrica Kloz.
Effettueremo DCI su MPLS L3VPN.

Una rete Overlay viene eseguita sulla rete fisica dell'host (potrebbe essere VXLAN o Tungsten Fabric di OpenStack o qualsiasi altra cosa che richieda solo la connettività IP di base dalla rete).

In questo caso, otteniamo uno scenario relativamente semplice per l'automazione, perché disponiamo di molte apparecchiature configurate allo stesso modo.

Sceglieremo una DC sferica nel vuoto:

• Una versione di design ovunque.
• Due fornitori che formano due piani di rete.
• Un DC è come un altro, come due piselli in un baccello.

contenuto

• Topologia fisica
• instradamento
• Piano IP
• Laba
• conclusione
• Link utili

Lascia che il nostro fornitore di servizi LAN_DC, ad esempio, ospiti video di formazione sulla sopravvivenza in ascensori bloccati.

Nelle megalopoli questo è molto popolare, quindi sono necessarie molte macchine fisiche.

Per prima cosa descriverò la rete approssimativamente come vorrei che fosse. E poi lo semplificherò per il laboratorio.

Topologia fisica

Posizioni

LAN_DC avrà 6 controller di dominio:

• Russia (RU):
  • Mosca (MSK)
  • Kazan (KZN)

• Spagna (SP):
  • Barcellona (BCN)
  • Málaga (MLG)

• Cina (CN):
  • Shangai (sha)
  • Xi'an (SIA)

All'interno di DC (Intra-DC)

Tutti i controller di dominio hanno reti di connettività interna identiche basate sulla topologia Clos.
Che tipo di reti Clos sono e perché sono separate Articolo.

Ogni DC ha 10 rack con macchine, saranno numerati come A, B, C E così via.

Ogni rack ha 30 macchine. Non ci interesseranno.

Inoltre in ogni rack c'è un interruttore a cui sono collegate tutte le macchine: questo è Interruttore nella parte superiore del rack: ToR o altrimenti la chiameremo fabbrica Clos foglia.

Schema generale dello stabilimento.

Li chiameremo XXX-fogliaYDove XXX - abbreviazione di tre lettere DC, e Y - numero di serie. Per esempio, kzn-foglia11.

Nei miei articoli mi permetterò di usare i termini Leaf e ToR come sinonimi in modo piuttosto frivolo. Dobbiamo però ricordare che non è così.
ToR è uno switch installato in un rack a cui sono collegate le macchine.
Leaf è il ruolo di un dispositivo in una rete fisica o di uno switch di primo livello in termini di topologia Cloes.
Cioè Foglia!= ToR.
Quindi Leaf può essere, ad esempio, un interruttore EndofRaw.
Tuttavia, nell'ambito di questo articolo li tratteremo comunque come sinonimi.

Ciascuno switch ToR è a sua volta collegato a quattro switch di aggregazione di livello superiore: Spina dorsale. Un rack nel DC è assegnato alle Spine. Lo chiameremo in modo simile: XXX-colonna vertebraleY.

Lo stesso rack conterrà gli apparati di rete per la connettività tra i router DC - 2 con MPLS a bordo. Ma nel complesso si tratta degli stessi ToR. Cioè, dal punto di vista degli switch Spine, il solito ToR con macchine connesse o un router per DCI non ha alcuna importanza, ma solo l'inoltro.

Vengono chiamati tali ToR speciali Foglia di bordo. Li chiameremo XXX-bordoY.

Sembrerà così.

Nel diagramma sopra, ho posizionato il bordo e la foglia allo stesso livello. Reti classiche a tre strati Ci hanno insegnato a considerare l'uplinking (da cui il termine) come uplink. E qui si scopre che il "link ascendente" DCI torna indietro, il che per alcuni rompe leggermente la solita logica. Nel caso di reti di grandi dimensioni, quando i data center sono divisi in unità ancora più piccole - POD's (Punto di consegna), evidenziare individuo Edge-PODper DCI e l'accesso alle reti esterne.

Per facilitare la percezione in futuro, disegnerò ancora Edge over Spine, mentre terremo presente che non c'è intelligenza su Spine e non ci sono differenze quando si lavora con Leaf e Edge-leaf regolari (anche se potrebbero esserci delle sfumature qui , ma in generale questo è vero).

Schema di una fabbrica con ante a bordo.

La trinità di Foglia, Spina e Bordo forma una rete o fabbrica Underlay.

Il compito di una fabbrica di rete (leggi Underlay), come abbiamo già definito in ultimo numero, molto, molto semplice: fornire connettività IP tra macchine sia all'interno dello stesso DC che tra di loro.
Ecco perché la rete si chiama fabbrica, proprio come, ad esempio, una fabbrica di commutazione all'interno di box di rete modulari, di cui potete leggere di più in SDSM14.

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

La fabbrica è completamente L3. Nessuna VLAN, nessuna trasmissione: abbiamo programmatori meravigliosi in LAN_DC, sanno come scrivere applicazioni che vivono nel paradigma L3 e le macchine virtuali non richiedono la migrazione live con conservazione dell'indirizzo IP.

E ancora una volta: la risposta alla domanda perché la fabbrica e perché L3 è separata Articolo.

DCI - Interconnessione del data center (Inter-DC)

I DCI saranno organizzati utilizzando gli Edge-Leaf, cioè saranno il nostro punto di uscita verso l'autostrada.
Per semplicità assumiamo che i DC siano collegati tra loro tramite collegamenti diretti.
Escludiamo dalla considerazione la connettività esterna.

Sono consapevole che ogni volta che rimuovo un componente semplifico notevolmente la rete. E quando automatizzeremo la nostra rete astratta, tutto andrà bene, ma su quella reale ci saranno le stampelle.
Questo è vero. Tuttavia, lo scopo di questa serie è pensare e lavorare su approcci, non risolvere eroicamente problemi immaginari.

Su Edge-Leaf, l'underlay viene posizionato nella VPN e trasmesso attraverso il backbone MPLS (lo stesso collegamento diretto).

Questo è il diagramma di primo livello che otteniamo.

instradamento

Per il routing all'interno del DC utilizzeremo BGP.
Sul trunk MPLS OSPF+LDP.
Per DCI, cioè, organizzare la connettività nel sottosuolo: BGP L3VPN su MPLS.

Schema generale del percorso

In fabbrica non sono presenti OSPF o ISIS (protocollo di routing vietato nella Federazione Russa).

Ciò significa che non ci sarà alcuna scoperta automatica o calcolo dei percorsi più brevi, ma solo l’impostazione manuale (in realtà automatica – stiamo parlando di automazione) del protocollo, del vicinato e delle politiche.

Schema di routing BGP all'interno del controller di dominio

Perché BGP?

Su questo argomento c'è intera RFC che prende il nome da Facebook e Arista, che racconta come costruire molto largo reti di data center che utilizzano BGP. Si legge quasi come una fiction, lo consiglio vivamente per una serata languida.

E c’è anche un’intera sezione del mio articolo dedicata a questo. Dove ti porto e sto inviando.

In breve, però, nessun IGP è adatto alle reti di grandi data center, dove il numero di dispositivi di rete ammonta a migliaia.

Inoltre, l'utilizzo di BGP ovunque ti consentirà di non perdere tempo nel supportare diversi protocolli diversi e nella sincronizzazione tra di loro.

In tutta sincerità, nella nostra fabbrica, che con un alto grado di probabilità non crescerà rapidamente, OSPF basterebbe per gli occhi. Questi sono in realtà i problemi dei megascaler e dei titani del cloud. Ma immaginiamo di averne bisogno solo per alcune versioni e utilizzeremo BGP, come ha lasciato in eredità Pyotr Lapukhov.

Politiche di instradamento

Sugli switch Leaf, importiamo i prefissi dalle interfacce di rete Underlay in BGP.
Avremo una sessione BGP nel mezzo a testa una coppia Leaf-Spine, in cui questi prefissi Underlay verranno annunciati sulla rete qua e là.

All'interno di un data center distribuiremo le specifiche che abbiamo importato in ToRe. Su Edge-Leaf li aggregheremo e li annunceremo ai DC remoti e li invieremo ai TOR. Cioè, ciascun ToR saprà esattamente come raggiungere un altro ToR nella stessa DC e dove si trova il punto di ingresso per raggiungere il ToR in un altro DC.

In DCI, i percorsi verranno trasmessi come VPNv4. Per fare questo, su Edge-Leaf, l'interfaccia verso la fabbrica sarà posta in una VRF, chiamiamola UNDERLAY, e l'intorno con Spine su Edge-Leaf sorgerà all'interno della VRF, e tra Edge-Leafs nella VPNv4- famiglia.

Proibiremo inoltre il riannuncio dei percorsi ricevuti dalle spine.

Su Leaf e Spine non importeremo i Loopback. Ne abbiamo bisogno solo per determinare l'ID del router.

Ma su Edge-Leafs lo importiamo in Global BGP. Tra gli indirizzi di Loopback, gli Edge-Leaf stabiliranno tra loro una sessione BGP nella famiglia VPN IPv4.

Avremo un backbone OSPF+LDP tra i dispositivi EDGE. Tutto è in una zona. Configurazione estremamente semplice.

Questa è l'immagine con il routing.

ASN BGP

ASN Edge-Leaf

Su Edge-Leafs ci sarà un ASN in tutti i DC. È importante che ci sia iBGP tra Edge-Leaf e non lasciamoci coinvolgere dalle sfumature di eBGP. Sia 65535. In realtà potrebbe essere il numero di un AS pubblico.

ASN della colonna vertebrale

Su Spine avremo un ASN per DC. Iniziamo qui con il primo numero della gamma di AS privati: 64512, 64513 e così via.

Perché ASN su DC?

Dividiamo questa domanda in due:

• Perché gli ASN sono gli stessi su tutti i dorsi di un DC?
• Perché sono diversi nei diversi DC?

Perché sono presenti gli stessi ASN su tutti i dorsi di un controller di dominio?

Questo è come apparirà l'AS-Path del percorso Underlay su Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Quando provi a pubblicizzarlo nuovamente su Spine, lo scarterà perché il suo AS (Spine_AS) è già nell'elenco.

Tuttavia, all'interno del DC siamo completamente soddisfatti che i percorsi Underlay che salgono al Bordo non potranno scendere. Tutte le comunicazioni tra host all'interno del DC devono avvenire all'interno del livello della colonna vertebrale.

In questo caso i percorsi aggregati di altri DC raggiungeranno comunque facilmente i ToR - il loro AS-Path avrà solo ASN 65535 - il numero di AS Edge-Leaf, perché è lì che sono stati creati.

Perché sono diversi nei diversi DC?

In teoria, potrebbe essere necessario trascinare Loopback e alcune macchine virtuali di servizio tra controller di dominio.

Ad esempio, sull'host eseguiremo Route Reflector o lo stesso VNGW (Virtual Network Gateway), che si bloccherà con TopR tramite BGP e annuncerà il suo loopback, che dovrebbe essere accessibile da tutti i controller di dominio.

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

E non dovrebbero esserci ASN duplicati da nessuna parte.

Cioè, Spine_DC1 e Spine_DC2 devono essere diversi, proprio come leafX_DC1 e leafY_DC2, che è esattamente ciò a cui ci stiamo avvicinando.

Come probabilmente saprai, esistono hack che ti consentono di accettare percorsi con ASN duplicati nonostante il meccanismo di prevenzione del loop (allowas-in su Cisco). E ha anche usi legittimi. Ma questa è una potenziale lacuna nella stabilità della rete. E personalmente ci sono caduto un paio di volte.

E se avremo la possibilità di non usare cose pericolose, ne approfitteremo.

ASN foglia

Avremo un ASN individuale su ogni switch Leaf in tutta la rete.
Lo facciamo per i motivi sopra indicati: percorso AS senza loop, configurazione BGP senza segnalibri.

Affinché i percorsi tra le Leaf passino senza intoppi, l'AS-Path dovrebbe assomigliare a questo:
[leafX_ASN, spine_ASN, leafY_ASN]
dove leafX_ASN e leafY_ASN sarebbe bello essere diversi.

Ciò è necessario anche nel caso dell'annuncio di un loopback VNF tra DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Utilizzeremo un ASN a 4 byte e lo genereremo in base all'ASN del dorso e al numero dello switch foglia, vale a dire in questo modo: Dorso_ASN.0000X.

Questa è la foto con l'ASN.

Piano IP

Fondamentalmente dobbiamo assegnare gli indirizzi per le seguenti connessioni:

1. Sottoporre gli indirizzi di rete tra ToR e la macchina. Devono essere unici all'interno dell'intera rete in modo che ogni macchina possa comunicare con qualsiasi altra. Ottima vestibilità 10/8. Per ogni rack ci sono /26 con riserva. Assegneremo /19 per DC e /17 per regione.
2. Indirizzi di collegamento tra Leaf/Tor e Spine.

   Vorrei assegnarli in modo algoritmico, cioè calcolarli a partire dai nomi dei dispositivi che devono essere collegati.

   Lascia che sia... 169.254.0.0/16.
   cioè, 169.254.00X.Y/31Dove X -Numero della colonna vertebrale, Y — Rete P2P /31.
   Ciò ti consentirà di lanciare fino a 128 rack e fino a 10 Spine nel DC. Gli indirizzi di collegamento possono (e saranno) ripetuti da DC a DC.

3. Organizziamo la giunzione Spine-Edge-Leaf su sottoreti 169.254.10X.Y/31, dove esattamente lo stesso X -Numero della colonna vertebrale, Y — Rete P2P /31.
4. Collegare gli indirizzi da Edge-Leaf al backbone MPLS. Qui la situazione è leggermente diversa: il luogo in cui tutti i pezzi sono collegati in un'unica torta, quindi riutilizzare gli stessi indirizzi non funzionerà: è necessario selezionare la successiva sottorete libera. Pertanto, prendiamo come base 192.168.0.0/16 e ne tireremo fuori quelli liberi.
5. Indirizzi di loopback. Daremo loro l'intera gamma 172.16.0.0/12.
   • Foglia - /25 per DC - gli stessi 128 rack. Assegneremo /23 per regione.
   • Dorso - /28 per CD - fino a 16 Dorso. Assegniamo /26 per regione.
   • Edge-Leaf - /29 per DC - fino a 8 scatole. Assegnamo /27 per regione.

Se non disponiamo di intervalli allocati sufficienti nel controller di dominio (e non ce ne saranno, affermiamo di essere hyperscaler), selezioniamo semplicemente il blocco successivo.

Questa è l'immagine con l'indirizzamento IP.

Loopback:

prefisso
Ruolo del dispositivo
Regione
DC

172.16.0.0/23
bordo
 
 

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
spina dorsale
 
 

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

Sottofondo:

prefisso
Regione
DC

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

Due venditori. Una rete. ADSM.

Ginepro + Arista. Ubuntu. Buona vecchia Eva.

La quantità di risorse sul nostro server virtuale a Mirana è ancora limitata, quindi per esercitarci utilizzeremo una rete semplificata al limite.

Due data center: Kazan e Barcellona.

• Due spine ciascuno: Ginepro e Arista.
• Un toro (Foglia) in ciascuno: Juniper e Arista, con un host connesso (prendiamo una lente Cisco IOL per questo).
• Un nodo Edge-Leaf ciascuno (per ora solo Juniper).
• Uno switch Cisco per domarli tutti.
• Oltre ai box di rete è in funzione una macchina di controllo virtuale. Eseguire Ubuntu.
  Ha accesso a tutti i dispositivi, eseguirà sistemi IPAM/DCIM, un sacco di script Python, Ansible e qualsiasi altra cosa di cui potremmo aver bisogno.

Configurazione completa di tutti i dispositivi di rete, che cercheremo di riprodurre utilizzando l'automazione.

conclusione

Anche questo è accettato? Dovrei scrivere una breve conclusione sotto ogni articolo?

Quindi abbiamo scelto tre livelli Rete Clos all'interno del DC, poiché ci aspettiamo molto traffico est-ovest e vogliamo ECMP.

La rete è stata divisa in fisica (underlay) e virtuale (overlay). Allo stesso tempo, l'overlay inizia dall'host, semplificando così i requisiti per l'underlay.

Abbiamo scelto BGP come protocollo di routing per le reti di rete per la sua scalabilità e flessibilità delle policy.

Avremo nodi separati per organizzare DCI - Edge-leaf.
La dorsale avrà OSPF+LDP.
DCI sarà implementato sulla base di MPLS L3VPN.
Per i collegamenti P2P, calcoleremo gli indirizzi IP in modo algoritmico in base ai nomi dei dispositivi.
Assegneremo i loopback in base al ruolo dei dispositivi e alla loro posizione in sequenza.
Prefissi sottostanti: solo sugli interruttori Leaf in sequenza in base alla loro posizione.

Supponiamo che in questo momento non abbiamo ancora l'attrezzatura installata.
Pertanto, i nostri prossimi passi saranno aggiungerli ai sistemi (IPAM, inventario), organizzare l'accesso, generare una configurazione e distribuirla.

Nel prossimo articolo ci occuperemo di Netbox, un sistema di inventario e gestione dello spazio IP in un DC.

Grazie

• Andrey Glazkov aka @glazgoo per la correzione di bozze e le correzioni
• Alexander Klimenko aka @v00lk per la correzione di bozze e le modifiche
• Artyom Chernobay per KDPV

Fonte: habr.com