Il SDSM è finito, ma il desiderio incontrollato di scrivere è rimasto.

Per molti anni, il nostro collega ha sofferto nell'eseguire compiti ripetitivi, incrociando le dita prima del commit e dormendo poco a causa dei rollback notturni.
Ma anche i tempi bui devono finire.

Con questo articolo inizierò una serie su come me la automazione è percepita.
Durante il percorso, esamineremo le fasi dell'automazione, la gestione delle variabili, la formalizzazione del design, il RestAPI, NETCONF, YANG, YDK e programmeremo molto.
Per me significa che a) non è una verità oggettiva, b) non è l'approccio migliore in modo incondizionato, c) il mio punto di vista potrebbe cambiare anche durante il cammino dall'articolo iniziale all'ultimo - onestamente, dalla bozza alla pubblicazione ho riscritto tutto due volte.

Contenuto

1. Obiettivi
   1. La rete è come un organismo unico
   2. Testare la configurazione
   3. Versioning
   4. Monitoraggio e auto-ripristino dei servizi

2. Strumenti
   1. Sistema di inventario
   2. Sistema di gestione dello spazio IP
   3. Sistema di descrizione dei servizi di rete
   4. Meccanismo di inizializzazione dei dispositivi
   5. Modello di configurazione indipendente dal fornitore
   6. Interfaccia specifica del fornitore con driver
   7. Meccanismo di consegna della configurazione ai dispositivi
   8. CI/CD
   9. Meccanismo di backup e ricerca delle anomalie
   10. Sistema di monitoraggio

3. Conclusione

Proverò a portare il ADSCM in un formato leggermente diverso dal SDSM. Ci saranno ancora articoli numerati ampi e tra di essi pubblicherò piccole note dall'esperienza quotidiana. Cercherò di combattere il perfezionismo e di non rifinire ognuno di essi.

È curioso che per la seconda volta debba percorrere lo stesso cammino.

Inizialmente ho dovuto scrivere articoli sulle reti perché non ce n'erano in Rete russa.

Ora non sono riuscito a trovare un documento completo che sistematizzasse gli approcci all'automazione e esplorasse le tecnologie menzionate attraverso esempi pratici semplici.

Potrei sbagliarmi, quindi inviatemi link a risorse valide. Tuttavia, questo non cambierà la mia determinazione a scrivere, poiché l'obiettivo principale è imparare qualcosa per me stesso, e rendere la vita più facile agli altri è un gradevole bonus che arricchisce la diffusione della conoscenza.

Proveremo a prendere un data center di medie dimensioni, il LAN DC, e lavoreremo su tutto lo schema di automazione.
Alcune cose le farò praticamente per la prima volta insieme a voi.

Nelle idee e negli strumenti descritti qui non sarò originale. Dmitry Figol ha un ottimo canale con streaming su questo argomento.
Gli articoli si sovrapporranno in molti aspetti con i suoi.

Nel LAN DC ci sono 4 DC, circa 250 switch, una mezza dozzina di router e un paio di firewall.
Non è Facebook, ma è sufficiente per riflettere profondamente sull'automazione.
Si dice, comunque, che se hai più di un dispositivo, hai già bisogno di automazione.
In realtà è difficile immaginare che qualcuno possa vivere senza almeno un pacchetto di script di automazione.
Anche se ho sentito che ci sono aziende dove la gestione degli indirizzi IP viene fatta in Excel e ogni migliaio di dispositivi di rete viene configurato manualmente con la propria configurazione unica. Certo, questo può essere considerato arte moderna, ma i sentimenti di un ingegnere sarebbero sicuramente offesi.

Obiettivi

Ora stabiliremo obiettivi massimamente astratti:

• La rete è come un organismo unico
• Testare la configurazione
• Versionamento dello stato della rete
• Monitoraggio e auto-ripristino dei servizi

Successivamente in questo articolo discuteremo quali strumenti utilizzeremo, e nei successivi sia gli obiettivi che i mezzi in dettaglio.

La rete è come un organismo unico

La frase determinante del ciclo, sebbene a prima vista possa sembrare insignificante: configureremo la rete, non i singoli dispositivi..
Negli ultimi anni abbiamo assistito a un cambiamento di enfasi verso il trattamento della rete come una singola entità, da cui nascono Networking definito dal software, Reti guidate dall'intento e Reti autonome.
Infatti, ciò di cui le applicazioni hanno bisogno dalla rete in modo globale: connessione tra i punti A e B (e a volte +B-Y) e isolamento dagli altri applicativi e utenti.

E quindi, il nostro compito in questa serie è costruire un sistemache supporti la configurazione attuale di tutta la reteche è già scomposta nella configurazione attuale di ciascun dispositivo in base al suo ruolo e posizione.
Sistema La gestione della rete implica che per apportare modifiche ci rivolgiamo a essa, e essa a sua volta calcola lo stato necessario per ciascun dispositivo e lo configura.
In questo modo minimizziamo quasi a zero il ricorso al CLI manualmente - qualsiasi modifica nelle impostazioni dei dispositivi o nel design della rete deve essere formalizzata e documentata - e solo dopo essere implementate sugli elementi necessari della rete.

Cioè, ad esempio, se decidiamo che da ora in poi gli switch di rack a Kazan devono annunciare due reti invece di una, noi

1. Documentiamo prima le modifiche nei sistemi
2. Generiamo la configurazione target di tutti i dispositivi della rete
3. Avviamo il programma di aggiornamento della configurazione di rete, che calcola cosa deve essere rimosso da ciascun nodo, cosa deve essere aggiunto e porta i nodi alla stato desiderato.

In questo caso, apportiamo modifiche manualmente solo al primo passo.

Testare la configurazione

È noto, che l'80% dei problemi si verifica durante la modifica della configurazione: una prova indiretta è che durante le festività di Capodanno normalmente tutto è tranquillo.
Ho personalmente assistito a decine di downtime globali a causa di errori umani: comandi sbagliati, eseguiti nella branch errata della configurazione, dimenticanze, cancellazione globale MPLS su un router, configurato cinque dispositivi, mentre sul sesto non ho notato l'errore, ho confermato vecchie modifiche fatte da un'altra persona. Gli scenari sono infiniti.

L'automazione ci permetterà di commettere meno errori, ma su una scala maggiore. Così si può bloccare non un solo dispositivo, ma tutta la rete contemporaneamente.

Da tempi immemori, i nostri antenati verificavano la correttezza delle modifiche apportate con un occhio attento, con nervi saldi e la funzionalità della rete dopo il rilascio.
Quegli antenati le cui operazioni portavano a inutilizzi e perdite catastrofiche lasciavano meno discendenti e dovevano estinguersi col tempo, ma l'evoluzione è un processo lento, e per questo non tutti controllano le modifiche in laboratorio.
Tuttavia, all'avanguardia del progresso ci sono quelli che hanno automatizzato il processo di test delle configurazioni e la loro applicazione sulla rete. In altre parole, hanno preso in prestito la procedura CI/CD (Continuous Integration, Continuous Deployment) dagli sviluppatori.
In una delle sezioni parleremo di come realizzare questo utilizzando un sistema di controllo versione, probabilmente GitHub.

Una volta che vi abituerete all'idea di una CI/CD di rete, il metodo di verifica della configurazione applicandola alla rete in produzione vi sembrerà subito un'ignoranza medievale, circa come colpire un testata con un martello.

Un'estensione organica delle idee di un sistema gestione della rete e CI/CD è una piena versionatura della configurazione.

Versioning

Considereremo che qualunque modifica, anche la più insignificante, anche su un dispositivo poco visibile, fa sì che l'intera rete passi da uno stato a un altro.
E noi non eseguiamo mai un comando su un dispositivo, ma cambiamo lo stato della rete.
Chiamiamo questi stati versioni?

Diciamo che la versione attuale è 1.0.0.
È cambiato l'indirizzo IP dell'interfaccia Loopback su uno dei ToR? Questa è una versione minore — otterrà il numero 1.0.1.
Se abbiamo rivisto le politiche di importazione dei percorsi in BGP — un po' più serio — è già 1.1.0.
Decidiamo di abbandonare l'IGP e passare solo a BGP — questo è già un cambiamento di design radicale — 2.0.0.

Inoltre, diversi DC possono avere versioni diverse — la rete si evolve, viene installato nuovo hardware, in alcuni casi si aggiungono nuovi livelli di spine, in altri no, ecc.

Riguardo versionamento semantico ne parleremo in un articolo separato.

Ripeto — ogni modifica (eccetto i comandi di debug) è un aggiornamento di versione. Gli amministratori devono essere informati di qualsiasi deviazione dalla versione attuale.

Lo stesso vale per il rollback delle modifiche — non è l'annullamento degli ultimi comandi, non è un rollback effettuato dal sistema operativo del dispositivo — è riportare l'intera rete a una nuova (o vecchia) versione.

Monitoraggio e auto-ripristino dei servizi

Questa è un compito ovvio nelle reti moderne che sale a un nuovo livello.
Spesso, nei grandi provider di servizi si pratica l'approccio per cui un servizio che è caduto deve essere rapidamente ripristinato e una nuova istanza avviata, invece di indagare su cosa sia successo.
"Rapidmente" significa che da tutti i lati è necessario assicurarsi di avere una sorveglianza abbondante, in grado di rivelare le più piccole deviazioni dalla norma in pochi secondi.
E qui non sono sufficienti le metriche abituali, come il carico dell'interfaccia o la disponibilità del nodo. Non basta neppure il monitoraggio manuale dell'operatore.
Per molte cose, in realtà, dovrebbe esserci Self-Healing — i monitor sono accesi di rosso e vanno a mettere una foglia di piantaggine dove fa male.

E qui monitoriamo non solo singoli dispositivi, ma anche la salute dell'intera rete, sia in bianco che in nero, il che è relativamente chiaro, ma anche più complesso.

Di cosa abbiamo bisogno per realizzare tali ambiziosi piani?

• Avere un elenco di tutti i dispositivi nella rete, la loro posizione, ruoli, modelli, versioni del software.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Avere un sistema di descrizione dei servizi di rete.
  IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH.
• Essere in grado di inizializzare un dispositivo.
  Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF
• Configurare il dispositivo e riportare la configurazione alla versione desiderata (comprese le versioni precedenti).
• Testare la configurazione
• Controllare periodicamente lo stato di tutti i dispositivi per eventuali anomalie e comunicare a chi di dovere.
  Di notte, qualcuno ha aggiunto silenziosamente una regola nell'ACL..
• Monitorare la funzionalità.

Strumenti

Sembra abbastanza complesso per cominciare a decomporre il progetto in componenti.

E saranno dieci:

1. Sistema di inventario
2. Sistema di gestione dello spazio IP
3. Sistema di descrizione dei servizi di rete
4. Meccanismo di inizializzazione dei dispositivi
5. Modello di configurazione indipendente dal fornitore
6. Interfaccia specifica del fornitore con driver
7. Meccanismo di consegna della configurazione ai dispositivi
8. CI/CD
9. Meccanismo di backup e ricerca delle anomalie
10. Sistema di monitoraggio

Questo, tra l'altro, è un esempio di come è cambiata la visione degli obiettivi del ciclo: nella bozza dei componenti c'erano 4.

Nell'illustrazione ho rappresentato tutti i componenti e il dispositivo stesso.
I componenti sovrapposti interagiscono tra loro.
Maggiore è il blocco, maggiore è l'attenzione necessaria a questo componente.

Componente 1. Sistema di inventario

È evidente che vogliamo sapere quale attrezzatura si trova dove, e a cosa è collegata.
Il sistema di inventario è una parte essenziale di qualsiasi azienda.
Spesso le aziende hanno un sistema di inventario separato per i dispositivi di rete, che si occupa di compiti più specifici.
Nel nostro ciclo di articoli ci riferiremo a questo come DCIM - Data Center Infrastructure Management. Anche se il termine DCIM, rigorosamente parlando, include molto di più.

Per i nostri scopi, in esso memorizzeremo le seguenti informazioni sul dispositivo:

• Numero di inventario
• Nome/descrizione
• Modello (Huawei CE12800, Juniper QFX5120 ecc.)
• Parametri distintivi (schede, interfacce ecc.)
• Ruolo (Leaf, Spine, Border Router ecc.)
• Posizione (regione, città, data center, rack, unità.)
• Interconnessioni tra i dispositivi
• Topologia di rete

È chiaro che vogliamo sapere tutto questo.
Ma sarà utile per l'automazione?
Assolutamente.
Ad esempio, sappiamo che in questo data center sui Leaf switch, se è Huawei, le ACL per filtrare un certo traffico devono essere applicate su VLAN, mentre se è Juniper, su un'unità 0 dell'interfaccia fisica.
Oppure è necessario distribuire un nuovo server Syslog su tutti i border del regione.

In esso memorizzeremo anche dispositivi di rete virtuali, come router virtuali o route reflectors. Possiamo aggiungere server DNS, NTP, Syslog e in generale tutto ciò che in un modo o nell'altro riguarda la rete.

Componente 2. Sistema di gestione dello spazio IP

Sì, e ai giorni nostri ci sono gruppi di persone che tengono traccia di prefissi e indirizzi IP in un file Excel. Ma l'approccio moderno è comunque un database, con un frontend su nginx/apache, API e ampie funzionalità per la registrazione di indirizzi IP e reti con suddivisione in VRF.
IPAM - Gestione degli indirizzi IP.

Per i nostri scopi, in esso memorizzeremo le seguenti informazioni:

• VLAN
• VRF
• Reti/Sottoreti
• Indirizzi IP
• Associazione degli indirizzi ai dispositivi, reti alle posizioni e numeri VLAN.

È evidente che vogliamo essere sicuri che, assegnando un nuovo indirizzo IP per il loopback del ToR, non ci imbatteremo nel fatto che sia già stato assegnato a qualcun altro. O che lo stesso prefisso sia stato utilizzato due volte in angoli diversi della rete.
Ma come aiuterà questo nell'automazione?
Facile.
Richiediamo al sistema un prefisso con funzione Loopbacks, in cui siano disponibili indirizzi IP da assegnare: se viene trovato, assegniamo l'indirizzo, se no, richiediamo la creazione di un nuovo prefisso.
Oppure, nella creazione della configurazione di un dispositivo, possiamo scoprire tramite questo stesso sistema in quale VRF dovrebbe trovarsi l'interfaccia.
E quando avviamo un nuovo server, uno script consulterà il sistema, scoprendo in quale switch server si trova, in quale porta e quale sottorete è assegnata all'interfaccia: da essa verrà assegnato l'indirizzo del server.

Sorge il desiderio di unire DCIM e IPAM in un unico sistema, per evitare di duplicare funzioni e gestire due entità simili.
Così faremo.

Componente 3. Sistema di descrizione dei servizi di rete

Se i primi due sistemi memorizzano variabili che devono ancora essere utilizzate in qualche modo, il terzo descrive per ogni ruolo del dispositivo come dovrebbe essere configurato.
È utile distinguere due tipi diversi di servizi di rete:

• Infrastrutturali
• Client.

I primi sono destinati a garantire la connettività di base e la gestione del dispositivo. Qui rientrano VTY, SNMP, NTP, Syslog, AAA, protocolli di routing, CoPP ecc.
I secondi offrono un servizio al cliente: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP ecc.
Naturalmente ci sono anche casi limite: come classificare MPLS LDP, BGP? Inoltre, i protocolli di routing possono essere utilizzati anche per i clienti. Ma non è fondamentale.

Entrambi i tipi di servizi si scompongono in primitive di configurazione:

• interfacce fisiche e logiche (tag/antitag, mtu)
• Indirizzi IP e VRF (IP, IPv6, VRF)
• ACL e politiche di gestione del traffico
• Protocolli (IGP, BGP, MPLS)
• Politiche di routing (liste di prefissi, comunità, filtri ASN).
• Servizi di supporto (SSH, NTP, LLDP, Syslog…)
• Ecc.

Non sono sicuro di come procederemo, ne discuteremo in un articolo separato.

Se vogliamo renderlo più concreto, potremmo descrivere quello che
Gli switch Leaf devono avere sessioni BGP con tutti gli switch Spine connessi, importare nella rete connessa e accettare solo le reti da parte degli switch Spine che appartengono a un determinato prefisso. Limitare il CoPP IPv6 ND a 10 pps, ecc.
A sua volta, gli Spine mantengono sessioni con tutti i Leaf connessi, fungendo da route reflectors, e accettano solo rotte di una certa lunghezza e con una specifica community.

Componente 4. Meccanismo di inizializzazione dispositivo

Sotto questo titolo unisco una serie di azioni che devono avvenire affinché il dispositivo appaia nei radar e possa essere raggiunto da remoto.

1. Registrare il dispositivo nel sistema di inventario.
2. Assegnare un indirizzo IP di gestione.
3. Configurare l'accesso di base a esso:
   Nome host, indirizzo IP di gestione, percorso nella rete di gestione, utenti, chiavi SSH, protocolli — telnet/SSH/NETCONF

Esistono tre approcci:

• Completamente manuale. Il dispositivo viene portato su un tavolo di test, dove una persona normale lo registrerà nei sistemi, si connetterà tramite console e lo configurerà. Può funzionare in piccole reti statiche.
• ZTP — Zero Touch Provisioning. L'hardware è arrivato, si è attaccato, ha ottenuto un indirizzo tramite DHCP e si è configurato autonomamente.
• Infrastruttura di server console, dove la configurazione iniziale avviene attraverso la porta console in modalità automatica.

Di tutti e tre parleremo in un articolo separato.

Componente 5. Modello di configurazione vendor-agnostico

Fino ad ora, tutti i sistemi erano patchwork disomogenei, fornendo descrizioni variabili e dichiarative di ciò che ci piacerebbe vedere nella rete. Ma prima o poi, dovremo affrontare la specificità.
In questa fase, per ogni dispositivo specifico, primitive, servizi e variabili vengono combinati in un modello di configurazione che descrive effettivamente la configurazione completa del dispositivo specifico, solo in modo vendor-indipendente.
Qual è il vantaggio di questo passaggio? Perché non formare immediatamente la configurazione del dispositivo che può essere semplicemente caricata?
In realtà, permette di affrontare tre compiti:

1. Non dover adattarsi a un'interfaccia specifica di interazione con il dispositivo. Che si tratti di CLI, NETCONF, RESTCONF, SNMP — il modello sarà identico.
2. Non mantenere un numero di template/script pari al numero di vendor nella rete, e in caso di modifica del design, cambiare la stessa cosa in più posti.
3. Caricare la configurazione da un dispositivo (backup), organizzandola in un modello esattamente uguale e confrontando direttamente la configurazione target con quella attuale per calcolare la differenza e preparare una patch di configurazione che modifichi solo le parti necessarie o per identificare le deviazioni.

A seguito di questo passaggio otteniamo una configurazione vendor-indipendente.

Componente 6. Driver specifico per interfaccia vendor

Non bisogna nutrire illusioni sull'idea che un giorno sarà possibile configurare un Cisco allo stesso modo di un Juniper, semplicemente inviando loro chiamate completamente identiche. Nonostante la crescente popolarità dei whitebox e l'emergere del supporto per NETCONF, RESTCONF, OpenConfig, il contenuto specifico fornito da questi protocolli varia da vendor a vendor, e questo è uno dei loro punti di differenza competitivi che non abbandoneranno facilmente.
Questo è esattamente simile a OpenContrail e OpenStack, che hanno REST API come interfaccia NorthBound, e si aspettano chiamate completamente diverse.

Pertanto, nel quinto passaggio, il modello vendor-indipendente deve assumere la forma che andrà sull'hardware.
E qui tutti i mezzi sono buoni (no): CLI, NETCONF, RESTCONF, SNMP — tutto può andar bene.

Quindi avremo bisogno di un driver che traduca il risultato del passaggio precedente nel formato necessario per il specifico vendor: un insieme di comandi CLI, una struttura XML.

Componente 7. Meccanismo di consegna della configurazione al dispositivo

La configurazione l'abbiamo generata, ma deve ancora essere consegnata ai dispositivi — e, chiaramente, non manualmente.
In primo luogoOra si pone la questione: quale trasporto utilizzeremo? E la scelta oggi è già ampia:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• richieste RESTCONF
• REST API
• OpenFlow (anche se esce dalla lista poiché è un modo per consegnare FIB e non configurazioni)

Chiarendo i termini. CLI è legacy. SNMP… ehm.
RESTCONF è ancora una bestia sconosciuta, le REST API non sono supportate quasi da nessuno. Pertanto, nel ciclo ci concentreremo su NETCONF.

In realtà, come già compreso dal lettore, a questo punto abbiamo già stabilito l'interfaccia — il risultato del passaggio precedente è già presentato nel formato di quell'interfaccia che è stata scelta.

In secondo luogoE quali strumenti utilizzeremo per farlo?
Qui la scelta è ampia:

• Script personalizzato o piattaforma. Armati di ncclient e asyncIO e facciamo tutto noi. Cosa ci impedisce di costruire un sistema di deployment da zero?
• Ansible con la sua ricca libreria di moduli di rete.
• Salt con la sua limitata gestione della rete e integrazione con Napalm.
• Proprio Napalm, che conosce alcuni vendor e poi basta, arrivederci.
• Nornir — un altro strumento che analizzeremo in futuro.

Qui non è ancora stato scelto un favorito — stiamo esplorando.

Cosa è importante qui? Le conseguenze dell'applicazione della configurazione.
Se ha successo o meno. Rimane l'accesso all'hardware o meno.
Sembra che un commit con conferma e validazione di ciò che è stato caricato nel dispositivo possa aiutare.
Questo, combinato con una corretta implementazione di NETCONF, restringe notevolmente il numero di dispositivi compatibili — gli impegni standard non sono supportati da molti produttori. Ma questo è solo uno dei requisiti in RFP. Alla fine nessuno si preoccupa che nessun fornitore russo soddisfi il requisito di 32*100GE interfaccia. O si preoccupa?

Componente 8. CI/CD

A questo punto abbiamo già configurato tutti i dispositivi di rete.
Scrivo "tutti" perché parliamo di versionamento dello stato della rete. E anche se è necessario cambiare le impostazioni di un solo switch, vengono calcolati i cambiamenti per tutta la rete. Ovviamente, questi possono essere nulli per la maggior parte dei nodi.

Ma, come già detto sopra, non siamo barbarici per lanciare tutto direttamente in produzione.
La configurazione generata deve prima passare attraverso il Pipeline CI/CD.

CI/CD significa Integrazione Continua, Distribuzione Continua. Questo approccio consente al team di non pubblicare un nuovo rilascio principale ogni sei mesi, sostituendo completamente il vecchio, ma di implementare regolarmente nuova funzionalità in piccole porzioni, ognuna delle quali viene testata a fondo per compatibilità, sicurezza e funzionalità.

A tal fine abbiamo un sistema di controllo versione che tiene traccia delle modifiche alla configurazione, un laboratorio dove verifichiamo che il servizio clienti non venga interrotto, un sistema di monitoraggio che verifica questo fatto, e l'ultimo passo — il rilascio delle modifiche alla rete operativa.

Ad eccezione dei comandi di debug, tutte le modifiche sulla rete devono passare attraverso il Pipeline CI/CD — questo è la nostra garanzia di una vita tranquilla e una carriera lunga e felice.

Componente 9. Sistema di backup e rilevamento delle anomalie

Non c'è bisogno di parlare troppo dei backup.
Li salveremo semplicemente cronologicamente o in base alle modifiche della configurazione in git.

Ma la seconda parte è più interessante — qualcuno deve sorvegliare questi backup. In alcuni casi, questa persona deve ripristinare tutto, mentre in altri, avvisare qualcuno che c'è un problema.
Ad esempio, se compare un nuovo utente che non è elencato nelle variabili, è meglio rimuoverlo per evitare intrusioni. E nel caso di una nuova regola firewall — meglio non toccarla, potrebbe essere che qualcuno abbia semplicemente attivato il debug, oppure un nuovo servizio, trascurato, non l'ha impostata secondo le linee guida, e ora gli utenti ci stanno accedendo.

Non possiamo evitarci dalle piccole deviazioni su scala dell'intera rete, nonostante qualsiasi sistema di automazione e una mano ferma nella gestione. Per il debugging dei problemi, comunque nessuno apporterà modifiche alla configurazione nei sistemi. Soprattutto, poiché il modello di configurazione potrebbe non prevederle nemmeno.

Ad esempio, una regola firewall per il conteggio dei pacchetti su un determinato IP, per localizzare il problema — è una configurazione temporanea del tutto ordinaria.

Componente 10. Sistema di monitoraggio

Inizialmente non intendevo trattare il tema del monitoraggio — è un argomento complesso, dibattuto e ampio. Ma si è rivelato essere una parte integrante dell'automazione. E non si può semplicemente ignorarlo, nemmeno senza pratica.

Sviluppando il pensiero — è una parte organica del processo CI/CD. Dopo il rilascio della configurazione sulla rete, dobbiamo essere in grado di determinare se ora va tutto bene.
E non si tratta solo e non tanto dei grafici di utilizzo delle interfacce o della disponibilità dei nodi, quanto di questioni più sottili — la presenza delle rotte necessarie, attributi su di esse, numero di sessioni BGP, vicini OSPF, funzionalità End-to-End dei servizi superiori.
E se i syslog non stanno più accumulandosi su un server esterno, o se l'agente SFlow non è guasto, o se non ci sia un aumento dei drop nelle code, o se non sia compromessa la connettività tra una certa coppia di prefissi?

In un articolo separato rifletteremo anche su questo.

Conclusione

Come base ho scelto uno dei design moderni delle reti di data center — L3 Clos Fabric con BGP come protocollo di routing.
Questa volta costruiremo la rete su Juniper, perché ora l'interfaccia JunOs è una meraviglia.

Ci complicheremo la vita utilizzando solo strumenti Open Source e una rete multivendor — quindi oltre a Juniper sceglierò anche un altro fortunato.

Il piano delle prossime pubblicazioni è più o meno questo:
Inizierò a parlare delle reti virtuali. Prima di tutto perché mi va, e in secondo luogo perché senza questo il design della rete infrastrutturale sarà poco chiaro.
Poi parlerò del design della rete: topologia, routing, politiche.
Costruiremo una lab stand.
Rifletteremo e, forse, faremo pratica con l'inizializzazione di un dispositivo in rete.
E poi approfondiremo ogni componente in dettagli intimi.

E sì, non prometto di concludere elegantemente questo ciclo con una soluzione pronta. 🙂

Link utili

• Prima di addentrarci nella serie, è consigliabile leggere il libro di Natasha Samoylenko Python per ingegneri di rete. E, forse, anche seguirlo con corso.
• Sarà utile anche leggere RFC sul design delle fabbriche di data center da Facebook, scritto da Petr Lapukhov.
• La documentazione sull'architettura ti darà un'idea di come funziona l'SDN Overlay Tungsten Fabric (precedentemente Open Contrail).

Grazie

Roman Gorge. Per i commenti e le correzioni.
Artyom Chernobai. Per KDPV.

Fonte: habr.com