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

Per molti anni, il nostro fratello ha sofferto nell'eseguire lavori di routine, incrociando le dita prima del commit e perdendo il sonno a causa dei rollback notturni.
Ma le oscurità avranno una fine.

Con questo articolo inizio una serie su come a me sembra l'automazione.
Durante il percorso, analizzeremo le fasi dell'automazione, la gestione delle variabili, la formalizzazione del design, con RestAPI, NETCONF, YANG, YDK e programmeremo molto.
Per me significa che a) non è una verità oggettiva, b) non è necessariamente il miglior approccio incondizionale, c) il mio punto di vista potrebbe cambiare anche nel corso della transizione dal primo all'ultimo articolo — onestamente, dalla fase di bozza alla pubblicazione ho riscritto tutto completamente due volte.

Contenuto

1. Obiettivi
   1. La rete è come un organismo unico
   2. Testing della configurazione
   3. Versionamento
   4. Monitoraggio e auto-recupero 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 agnostico rispetto al fornitore
   6. Driver specifico per interfaccia del fornitore
   7. Meccanismo di consegna della configurazione al dispositivo
   8. CI/CD
   9. Meccanismo di backup e rilevamento delle anomalie
   10. Sistema di monitoraggio

3. Conclusione

Cercherò di mantenere l'ADSM in un formato leggermente diverso dal SDSM. Continueranno a essere pubblicati articoli numerati dettagliati, e tra di essi pubblicherò piccole note dall'esperienza quotidiana. Cercherò di combattere qui con il perfezionismo e di non rifinire ciascuno di essi.

È divertente dover intraprendere lo stesso percorso per la seconda volta.

All'inizio ho dovuto scrivere io stesso articoli sulle reti perché non ce n'erano in Runet.

Ora non sono riuscito a trovare un documento esaustivo che sistematizzasse gli approcci all'automazione e analizzasse con esempi pratici le tecnologie sopracitate.

Potrei sbagliarmi, quindi inviatemi link a risorse utili. Tuttavia, ciò non cambierà la mia determinazione a scrivere, perché l'obiettivo principale è comunque imparare qualcosa di nuovo, mentre facilitare la vita agli altri è un piacevole bonus che soddisfa il gene della condivisione delle conoscenze.

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

Nelle idee e negli strumenti descritti qui non sarò originale. Dmitrij Figol ha un ottimo canale con streaming su questo tema.
Gli articoli si sovrapporranno a molti aspetti.

In LAN DC 4 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 avete più di un dispositivo, l'automazione è già necessaria.
In realtà è difficile immaginare che qualcuno possa vivere senza almeno un pacchetto di script per le ginocchia.
Tuttavia, ho sentito che ci sono aziende dove la gestione degli indirizzi IP avviene in Excel, e ciascuno dei migliaia di dispositivi di rete viene configurato manualmente e ha la propria configurazione unica. Questo, ovviamente, può essere considerato arte moderna, ma i sentimenti di un ingegnere saranno certamente offesi.

Obiettivi

Adesso poniamo obiettivi massimamente astratti:

• La rete è come un organismo unico
• Testing della configurazione
• Versionamento dello stato della rete
• Monitoraggio e auto-recupero dei servizi

Più avanti in questo articolo discuteremo quali strumenti utilizzeremo, e nei prossimi articoli, obiettivi e strumenti in dettaglio.

La rete è come un organismo unico

La frase determinante del ciclo, anche se a prima vista può sembrare non così significativa: configureremo la rete, non i singoli dispositivi.
Negli ultimi anni abbiamo osservato uno spostamento di accenti verso la gestione della rete come un'entità unica, da cui provengono Software Defined Networking, Intent Driven Networks e Autonomous Networks.
Infatti, cosa serve essenzialmente alle applicazioni dalla rete: connettività tra i punti A e B (beh, a volte +V-Я) e isolamento da altre applicazioni e utenti.

E così, il nostro compito in questa serie è costruire un sistema, che supporti la configurazione attuale dell'intera rete, che già si decompone nella configurazione attuale su 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 l'utilizzo manuale della CLI - qualsiasi modifica nelle impostazioni dei dispositivi o nel design della rete deve essere formalizzata e documentata - e solo dopo deve essere applicata agli elementi necessari della rete.

Cioè, ad esempio, se abbiamo deciso che da questo momento gli switch a torre a Kazan devono annunciare due reti invece di una, noi

1. Per prima cosa documentiamo le modifiche nei sistemi
2. Generiamo la configurazione target di tutti i dispositivi della rete
3. Avviamo il programma di aggiornamento della configurazione della rete, che calcola cosa deve essere rimosso su ogni nodo, cosa aggiungere e porta i nodi allo stato desiderato.

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

Testing della configurazione

È noto, che l'80% dei problemi si verifica durante la modifica della configurazione: una prova indiretta è che durante le festività natalizie di solito tutto è tranquillo.
Personalmente ho assistito a decine di downtime globali a causa di errori umani: un comando errato, eseguito in un ramo di configurazione sbagliato, dimenticata la comunità, cancellato MPLS globalmente su un router, configurate cinque macchine, ma sul sesto abbiamo notato un errore e abbiamo confermato vecchie modifiche fatte da un'altra persona. Ci sono innumerevoli scenari.

L'automazione ci permetterà di commettere meno errori, ma su scala più ampia. Così si può bloccare non un singolo dispositivo, ma l'intera rete contemporaneamente.

Fin dai tempi antichi i nostri antenati verificavano la correttezza delle modifiche apportate con occhio acuto, palle di acciaio e funzionalità della rete dopo il rilascio.
Quegli antenati il cui lavoro portava a fermi e perdite catastrofiche lasciavano meno discendenti e nel tempo dovevano estinguersi, ma l'evoluzione è un processo lento, e quindi ancora oggi non tutti verificano le modifiche in laboratorio.
Tuttavia, all'avanguardia del progresso ci sono coloro che hanno automatizzato il processo di test della configurazione e il suo ulteriore utilizzo sulla rete. In altre parole, hanno prelevato la procedura CI/CD (Continuous Integration, Continuous Deployment) dagli sviluppatori.
In una delle sezioni esamineremo come realizzarlo utilizzando un sistema di controllo versioni, probabilmente GitHub.

Non appena ti abituerai all'idea di CI/CD nella rete, all'improvviso il metodo di verifica della configurazione applicandola alla rete operativa ti sembrerà una forma di ignoranza medievale. Circa come colpire una testata missilistica con un martello.

L'evoluzione organica delle idee sulla sistema di gestione della rete e CI/CD diventa un vero e proprio versionamento della configurazione.

Versionamento

Consideriamo che con qualsiasi cambiamento, anche il più insignificante, anche su un dispositivo poco visibile, tutta la rete passi da uno stato a un altro.
E noi non eseguiamo mai il comando su un dispositivo, cambiamo lo stato della rete.
Diciamo che questi stati li chiameremo versioni?

Supponiamo che l'attuale versione sia 1.0.0.
È cambiato l'indirizzo IP dell'interfaccia Loopback su uno dei ToR? Questa è una versione minore - avrà il numero 1.0.1.
Se abbiamo modificato le politiche di importazione delle rotte in BGP - un po' più serio - siamo già a 1.1.0.
Se abbiamo deciso di eliminare l'IGP e passare solo a BGP - questo è già un cambiamento radicale di design - 2.0.0.

Inoltre, diversi DC possono avere versioni diverse - la rete si evolve, vengono installati nuovi dispositivi, dove vengono aggiunti nuovi livelli di spine, dove no, ecc.

Su il versionamento semantico ne parleremo in un articolo separato.

Ribadisco - qualsiasi cambiamento (eccettuate le comandi di debug) è un aggiornamento di versione. Gli amministratori devono essere avvisati di qualsiasi deviazione dalla versione attuale.

Lo stesso vale per il rollback delle modifiche - non si tratta dell'annullamento degli ultimi comandi, non è un rollback tramite il sistema operativo del dispositivo - si tratta di riportare tutta la rete a una nuova (o vecchia) versione.

Monitoraggio e auto-recupero dei servizi

Questa è un compito ovvio nelle reti moderne che raggiunge un nuovo livello.
Spesso, tra i grandi provider di servizi, si pratica l'approccio di dover velocemente distruggere un servizio caduto e alzare un nuovo, invece di capire cosa sia successo.
«Velocemente» significa che da tutte le parti bisogna coprirsi abbondantemente di monitoraggi, che in pochi secondi rileveranno le più piccole deviazioni dalla norma.
E qui non sono sufficienti le metriche familiari, come il carico dell'interfaccia o la disponibilità del nodo. Non basta neanche il monitoraggio manuale dell'operatore.
Per molte cose deve esserci Self-Healing — i monitoraggi si accendono di rosso e si attivano automaticamente, curando dove fa male.

E qui monitoriamo non solo singoli dispositivi, ma anche la salute dell'intera rete, sia in modalità whitebox, che è relativamente chiara, sia in blackbox, che è già più complessa.

Di cosa abbiamo bisogno per realizzare tali ambiziosi piani?

• Avere un elenco di tutti i dispositivi nella rete, la loro posizione, ruoli, modelli, versioni di 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 il dispositivo.
  Hostname, Mgmt IP, Mgmt Route, Utenti, RSA-Keys, LLDP, NETCONF
• Configurare il dispositivo e riportare la configurazione alla versione desiderata (inclusa quella precedente).
• Testare la configurazione
• Controllare periodicamente lo stato di tutti i dispositivi per verificare eventuali deviazioni e informare gli interessati.
  Di notte qualcuno ha silenziosamente aggiunto una regola nell'ACL.
• Monitorare la funzionalità.

Strumenti

Sembra abbastanza complicato per iniziare 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 agnostico rispetto al fornitore
6. Driver specifico per interfaccia del fornitore
7. Meccanismo di consegna della configurazione al dispositivo
8. CI/CD
9. Meccanismo di backup e rilevamento 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 ce n'erano 4.

Nell'illustrazione ho rappresentato tutti i componenti e il dispositivo stesso.
I componenti sovrapposti interagiscono tra loro.
Più è grande il blocco, maggiore attenzione deve essere dedicata 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, per i dispositivi di rete, l'azienda ha un sistema di inventario separato che affronta compiti più specifici.
Nell'ambito del ciclo di articoli lo chiameremo DCIM - Data Center Infrastructure Management. Sebbene il termine DCIM, rigorosamente parlando, includa molto di più.

Per le nostre esigenze, in esso memorizzeremo le seguenti informazioni sul dispositivo:

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

È ben chiaro che ci piacerebbe sapere tutto questo.
Ma questo aiuterà nell'automazione?
Senza dubbio.
Ad esempio, sappiamo che in questo data center sui commutatori Leaf, se si tratta di Huawei, le ACL per filtrare un certo tipo di traffico devono essere applicate alla VLAN, e se si tratta di Juniper, devono essere applicate all'unità 0 dell'interfaccia fisica.
O è necessario distribuire un nuovo server Syslog su tutti i border del regionale.

In essa memorizzeremo anche dispositivi di rete virtuali, ad esempio router virtuali o route reflector. Possiamo aggiungere server DNS, NTP, Syslog e in generale tutto ciò che riguarda la rete.

Componente 2. Sistema di gestione dello spazio IP

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

Per le nostre esigenze, in esso conserveremo le seguenti informazioni:

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

Ancora una volta, è chiaro che vogliamo assicurarci che, assegnando un nuovo indirizzo IP per il loopback del ToR, non ci imbatteremo nel fatto che è già stato assegnato a qualcun altro. O che lo stesso prefisso sia stato utilizzato due volte in diverse estremità della rete.
Ma come aiuterà questo nell'automazione?
Facile.
Richiediamo al sistema un prefisso con ruolo di Loopbacks, in cui ci siano indirizzi IP disponibili per l'assegnazione — se trovato, assegniamo l'indirizzo, se no, richiediamo la creazione di un nuovo prefisso.
Oppure, durante la creazione della configurazione di un dispositivo, possiamo sapere da questo stesso sistema in quale VRF deve trovarsi l'interfaccia.
E quando attiviamo un nuovo server, lo script accede al sistema, scopre in quale switch server, in quale porta e quale sottorete è assegnata all'interfaccia — da essa verrà assegnato l'indirizzo del server.

Sorge la volontà di unire DCIM e IPAM in un unico sistema, per evitare di duplicare le funzioni e gestire due entità simili.
E così faremo.

Componente 3. Sistema di descrizione dei servizi di rete

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

• Infrastrutturali
• Clienti.

I primi sono progettati per garantire la connettività di base e la gestione del dispositivo. Qui possiamo includere VTY, SNMP, NTP, Syslog, AAA, protocolli di routing, CoPP, ecc.
I secondi organizzano un servizio per il cliente: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, ecc.
Naturalmente, ci sono anche casi borderline — dove collocare MPLS LDP, BGP? E i protocolli di routing possono essere utilizzati per i clienti. Ma questo non è fondamentale.

Entrambi i tipi di servizi vengono suddivisi in primitivi di configurazione:

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

Non so ancora come lo faremo esattamente. Ne parleremo in un articolo separato.

Se parliamo di situazioni più concrete, potremmo descrivere che
Lo switch Leaf deve avere sessioni BGP con tutti gli switch Spine collegati, importare nel processo le reti collegate, accettare solo reti da un certo prefisso dagli switch Spine. Limitare CoPP IPv6 ND a 10 pps ecc.
A sua volta, gli Spine mantengono sessioni con tutti i Leaf collegati, fungendo da route reflector, e accettano solo percorsi di una certa lunghezza e con una certa community.

Componente 4. Meccanismo di inizializzazione del dispositivo

Sotto questo titolo riunisco molteplici azioni che devono avvenire affinché il dispositivo appaia sugli schermi e possa essere raggiunto da remoto.

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

Esistono tre approcci:

• Completamente tutto manuale. Il dispositivo viene portato su un banco di prova, dove una persona normale lo registra nei sistemi, si connette tramite console e lo configura. Questo può funzionare in piccole reti statiche.
• ZTP — Zero Touch Provisioning. L'hardware è arrivato, si è posizionato, ha ricevuto un indirizzo tramite DHCP, è andato su un server speciale, si è auto-configurato.
• Infrastruttura dei server di console, dove la configurazione primaria avviene tramite la porta della console in modalità automatica.

Parleremo di tutti e tre in un articolo separato.

Componente 5. Modello di configurazione vendor-agnostic

Fino ad ora, tutti i sistemi erano pezzi frammentati, che fornivano descrizioni variabili e dichiarative di ciò che ci piacerebbe vedere nella rete. Ma prima o poi, sarà necessario affrontare la concretezza.
A questo punto per ogni specifico dispositivo, le primitive, i servizi e le variabili vengono combinati in un modello di configurazione, che descrive effettivamente la configurazione completa di un dispositivo specifico, solo in modo non dipendente dal fornitore.
Qual è il vantaggio di questo passo? Perché non creare immediatamente la configurazione del dispositivo, che può essere semplicemente caricata?
In realtà, questo consente di risolvere tre compiti:

1. Non adattarsi a un'interfaccia di interazione specifica con il dispositivo. Che si tratti di CLI, NETCONF, RESTCONF, SNMP, il modello sarà lo stesso.
2. Non mantenere il numero di modelli/script in base al numero di vendor nella rete e, in caso di modifica del design, cambiare la stessa cosa in più posti.
3. Caricare la configurazione dal dispositivo (backup), predisporla in esattamente lo stesso modello e confrontare direttamente la configurazione target e quella esistente per calcolare la delta e preparare un patch di configurazione che modificherà solo le parti necessarie o per identificare le deviazioni.

Come risultato di questa fase, otteniamo una configurazione indipendente dal vendor.

Componente 6. Driver specifico dell'interfaccia vendor

Non illuderti che un giorno sarà possibile configurare un dispositivo Cisco esattamente come un Juniper, semplicemente inviando loro chiamate identiche. Nonostante la crescente popolarità dei whitebox e l'emergere del supporto per NETCONF, RESTCONF, OpenConfig, il contenuto specifico che questi protocolli forniscono varia da vendor a vendor, e questo è uno dei loro distintivi competitivi che non cederanno facilmente.
È più o meno come OpenContrail e OpenStack, che hanno il RestAPI come la loro interfaccia NorthBound, ma si aspettano chiamate completamente diverse.

Dunque, al quinto passo, il modello indipendente dal vendor deve assumere la forma in cui andrà sull'hardware.
E in questo caso è lecito usare qualsiasi mezzo: CLI, NETCONF, RESTCONF, SNMP, chi se ne frega.

Pertanto, abbiamo bisogno di un driver che traduca il risultato del passo precedente nel formato necessario per il particolare vendor: set di comandi CLI, struttura XML.

Componente 7. Meccanismo di consegna della configurazione al dispositivo

Abbiamo generato la configurazione, ma ora dobbiamo consegnarla ai dispositivi - e ovviamente non manualmente.
Primo, ci si pone la domanda: quale trasporto utilizzeremo? E al giorno d'oggi le opzioni non mancano:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (anche se esce un po' dal contesto, poiché è un modo per consegnare FIB, non configurazioni)

Diamo qui chiarimenti. CLI è legacy. SNMP... ehm... ehm.
RESTCONF è ancora una bestia sconosciuta, l'API REST non è supportata praticamente da nessuno. Quindi, nel ciclo ci concentreremo su NETCONF.

In realtà, come già compreso dal lettore, con l'interfaccia ci siamo già chiariti a questo punto: il risultato del passaggio precedente è già presentato nel formato di quell'interfaccia che è stata scelta.

In secondo luogo, quali strumenti utilizzeremo per farlo?
Qui c'è anche una grande scelta:

• Uno script personalizzato o una piattaforma. Armati di ncclient e asyncIO, faremo tutto da soli. Che ci vuole, costruire un sistema di deployment da zero?
• Ansible con la sua ricca libreria di moduli di rete.
• Salt con il suo scarso supporto per le reti e il collegamento con Napalm.
• Il vero Napalm, che conosce un paio di vendor e basta, arrivederci.
• Nornir è un'altra bestia che tratteremo in futuro.

Qui non è ancora stato scelto un favorito: daremo un'occhiata.

Cosa è importante qui? Le conseguenze dell'applicazione della configurazione.
Con successo o meno. C'è ancora accesso all'hardware o no.
Sembra che in questo caso un commit con conferma e validazione di ciò che è stato caricato sul dispositivo possa aiutare.
Questo, insieme a una corretta implementazione di NETCONF, restringe notevolmente il numero di dispositivi adatti: commit normali non sono supportati da così tanti produttori. Ma questo è semplicemente uno dei requisiti essenziali in RFP. Alla fine, nessuno si preoccupa se nessun vendor russo può soddisfare la condizione di un'interfaccia 32*100GE. O si preoccupa?

Componente 8. CI/CD

A questo punto abbiamo già pronte le configurazioni per tutti i dispositivi della rete.
Scrivo "per tutti" perché stiamo parlando di versioning dello stato della rete. E anche se è necessario cambiare le impostazioni di un solo switch, vengono calcolate le modifiche per l'intera rete. Ovviamente, queste possono risultare nulle per la maggior parte dei nodi.

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

CI/CD significa Continuous Integration, Continuous Deployment. Questo approccio prevede che il team non rilasci una nuova major release ogni sei mesi sostituendo completamente la precedente, ma implementi regolarmente in modo incrementale (Deployment) nuove funzionalità in piccole porzioni, ciascuna delle quali viene testata approfonditamente per compatibilità, sicurezza e funzionalità (Integration).

Per questo abbiamo un sistema di controllo delle versioni che tiene traccia delle modifiche nella configurazione, un laboratorio in cui viene testato se il servizio client non si rompe, un sistema di monitoraggio che verifica questo e l'ultimo passaggio è il rilascio delle modifiche nella rete operativa.

Ad eccezione dei comandi di debug, tutti i cambiamenti sulla rete devono passare attraverso il CI/CD Pipeline: è la nostra garanzia di una vita serena e di una lunga carriera felice.

Componente 9. Sistema di backup e ricerca delle anomalie

Non c'è bisogno di ribadire l'importanza dei backup.
Li archivieremo semplicemente in cron o in base alle modifiche nella configurazione su git.

Ma la seconda parte è più interessante: qualcuno deve sorvegliare questi backup. E in alcuni casi, questa persona deve tornare indietro e ripristinare tutto com'era, in altri casi, avvertire qualcuno che c'è un problema.
Ad esempio, se appare un nuovo utente non presente nelle variabili, deve essere rimosso per evitare problemi. E se c'è una nuova regola firewall, è meglio non toccarla, forse qualcuno ha semplicemente attivato il debug, o forse un nuovo servizio non l'ha registrata correttamente, mentre la gente già ci sta accedendo.

Da una certa piccola delta nell'ambito dell'intera rete non possiamo comunque scappare, nonostante qualsiasi sistema di automazione e la mano ferma della direzione. Per la risoluzione dei problemi, comunque, nessuno andrà a modificare la configurazione nei sistemi. Tanto più che la loro modifica potrebbe non essere nemmeno prevista dal modello di configurazione.

Ad esempio, una regola firewall per contare il numero di pacchetti su un certo IP per localizzare il problema è un'ordinaria configurazione temporanea.

Componente 10. Sistema di monitoraggio

All'inizio non avrei voluto trattare l'argomento del monitoraggio, poiché è un tema ampio, controverso e complesso. Ma nel corso dei lavori è diventato chiaro che è una parte integrante dell'automazione. E non è possibile evitarlo, nemmeno senza esperienza pratica.

Sviluppando il concetto, è una parte organica del processo CI/CD. Dopo il rilascio della configurazione sulla rete, dobbiamo essere in grado di determinare se tutto ora va bene.
E si tratta non solo e non tanto dei grafici di utilizzo delle interfacce o della disponibilità dei nodi, ma di questioni più sottili: la presenza delle rotte necessarie, degli attributi su di esse, del numero di sessioni BGP, dei vicini OSPF, della funzionalità end-to-end dei servizi superiori.
E se i syslog smettessero di accumularsi sul server esterno, se l'agente SFlow si fosse guasto, se i drop nelle code cominciassero ad aumentare, o se la connettività tra una coppia di prefissi fosse compromessa?

In un articolo separato rifletteremo anche su questo.

Conclusione

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

Ci complichiamo la vita utilizzando solo strumenti Open Source e una rete multi-vendor, quindi oltre a Juniper sceglierò anche un altro fortunato.

Il piano delle pubblicazioni prossime è più o meno questo:
Inizialmente parlerò delle reti virtuali. Prima di tutto, perché mi interessa, e in secondo luogo, perché senza di esse il design della rete infrastrutturale non sarà molto chiaro.
Poi parlerò del design della rete: topologia, routing, politiche.
Costruiremo una configurazione di laboratorio.
Rifletteremo e, magari, faremo pratica nell'inizializzazione di un dispositivo nella rete.
E poi parleremo di ogni componente in dettagli intimi.

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

Link utili

• Prima di addentrarci nella serie, vale la pena leggere il libro di Natasha Samoylenko Python per ingegneri di rete. E, forse, anche seguire un corso.
• Sarà utile anche leggere RFC sul design delle fabbriche dei data center di Facebook scritto da Petr Lapukhov.
• Come funziona SDN Overlay ti darà un'idea la documentazione relativa all'architettura Tungsten Fabric (precedentemente Open Contrail).

Grazie a

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

Fonte: habr.com